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Reface 


This  study  was  initiated  widi  the  goal  of  developing  a  mne  mature  framework  for  building 
and  validating  mathematical  models.  Since  modeling  is  oft»i  the  most  cost  effective  way  to 
investigate  die  impact  of  decisims,  it  is  likely  to  become  even  more  inqioitant  in  this  decade  of 
**do  more  with  less”.  Most  models  in  use  today  were  developed  “the  old  fashion  way”  where  the 
analyst  assigned  to  a  proUem  develops  a  model  formulation  which  is  passed  to  other  analysts 
who  improve  upon  it  Thus,  the  model  evolves  throu^  dme  into  a  useful  decision-making  tool 
(maybe).  Unfortunately,  the  usual  result  of  this  process  of  model  evolution  is  a  complicated 
patchwoik  model  that  seems  to  provide  good  answers  but  no  one  knows  how  or  why. 

Since  the  goal  of  modeling  is  insist  -  not  numbers  -  it  is  inqierative  that  Ae  models 
developed  for  the  Air  Force  be  useful,  understandable,  and  maintainable.  This  requires  a 
controlled  process  witii  more  emphasis  on  requirements,  documentation,  and  configuration 
management  Thus,  the  life  cycle  approach  is  born.  Since  the  life  cycle  of  a  model  is  a  process, 
the  next  step  on  the  “maturity  ladder”  might  be  called  process  control  I  leave  this  topic  for 
follow  <m  research. 

I  am  indebted  to  my  faculty  advisor.  Dr.  Chrissis,  for  his  patience  and  expertise,  and  to  my 
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Litko  and  hfr*.  Alan  WMsman  of  the  Force  Structure  Analysis  Division  at  Air  Mobility  Command 
for  tiieir  outstanding  help  in  working  with  the  ACEP  model  and  obtaining  the  Desen  SMeld  data 
Despite  my  initial  skepticism,  Lt  Col  Litko’s  predictions  on  the  improvements  needed  in  the 
model  turned  out  to  be  amazingly  accurate.  Finally,  I  must  thank  my  wife,  Susan,  for  her 
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Abstract 

This  study  investigates  the  q)plication  of  a  life  cycle  approach  to  the  validation  of 
operational  models.  The  classic  “waterfall”  life  cycle  from  software  engineering  is  adapted  for 
use  (H)  mathematical  models  by  defining  four  stages  of  model  development  Each  stage  is 
discussed  in  detail  and  examples  of  the  output  from  each  stage  are  presented.  In  addition, 
techniques  are  investigated  for  applying  the  proposed  life  cycle  to  existing  models  through  the 
recovery  of  life  cycle  stages. 

The  methodology  is  applied  to  a  linear  programming  model  developed  for  plamiing  airiift 
ope  'dons  to  demonstrate  the  power  of  the  life  cycle  approach  to  validation.  The  results  of 
applying  each  stage  of  the  life  cycle  to  the  model  are  presented.  As  a  final  test,  the  model  is  used 
to  predict  the  airlift  capability  and  resource  requirements  for  the  Operation  l>esert  Shield  airlift  A 
comparison  is  made  between  the  predictions  of  the  model  and  data  from  the  actual  operatioa  The 
validated  model  is  shown  to  be  a  better  representation  of  the  airlift  planning  problem.  Finally, 
specific  recommendations  are  made  for  operational  use  of  the  airlift  planning  model  and  on  areas 
where  further  research  is  needed  on  both  the  model  and  the  life  cycle  validation  approach. 
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THE  ATRI  TFT  r  APARH  ITTRS  ESTIMATIQN  PROTOTYPE: 

A  CASE  STUDY  IN  MODEL  VAUDATTON 

I.  LUToducdm 

ProMem  Statement 

The  effective  projection  of  combat  power  over  great  distances  is  now,  mor^  than  ever,  an 
in:q)ortant  task  of  the  United  States  armed  forces.  The  Air  Force  plays  a  crucial  role  in  achieving 
this  goal  througii  the  enqrloyment  of  airlift  forces.  Yet  with  a  shrinking  budget  and  force  size, 
iirqnovements  in  force  projecdon  cq)ability  must  come  from  more  effective  use  of  aircraft  and 
crews.  One  way  to  achieve  tins  is  throu^  the  efticient  scheduling  and  routing  of  aircraft  during 
an  airlift  operation.  Air  Force  planners  have  sophisticated  tools  availaUe  to  help  develop  airlift 
plans  for  specific  scenarios,  but  the  massive  airlift  operation  of  Desert  Shield  erqrosed 
weaknesses  in  these  tools.  The  tools  were  unable  to  keep  pace  with  the  fast-changing 
requirements  and  priorities  of  the  early  stages  of  the  operation.  The  purpose  of  this  thesis  is  to 
examine  the  Airlift  Capalnlities  Estimation  Prototype  (ACEP),  a  model  proposed  as  a  solution  to 
this  weakness,  and  investigate  how  well  it  meets  the  airlift  planning  challenge. 

Background 

Impatance  of  Strategic  Motility.  Future  conflicts  are  likely  to  be  short,  violent,  and  a  long 
way  from  U.S.  shores.  The  Persian  Gulf  deployment  was  the  prototype.  The  role  Of 
transpoitaticHi,  while  an  irrqrortant  aspect  of  any  military  action,  was  made  starkly  visible  this 
time.  “Anytime  we  have  to  take  an  action,  we  will  have  to  move  a  force  very,  very  quickly. 

From  a  strategy  stanc^oint,  I  see  transportation  being  of  increased  irrqrortance”  says  General 
RT.  Johnson,  commander  in  chief  of  U.S.  Transportation  Command  [Powell,  1991 :52].  U.S. 
strategic  moUlity  forces  moved  some  35,000  troops  and  1  billion  pounds  of  cargo  in  the  first  two 
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weeks  of  the  Persian  Gwf  deployment,  helping  deter  Iraq  from  attacking  Saudi  AraWa.  “The 
United  States  projected  forces,  equipment,  and  sustainment  farther,  faster  and  in  greater 
quantities  than  ever  before.”  [Condurt  of  the  Persian  Gulf  War,  1 992:  E-6]. 

Recent  worid  events  have  increased  the  importance  of  strategic  mobility.  The  uiq)araUeled 
metamoiphosis  of  our  old  nemesis,  die  former  Union  of  Soviet  Socialist  Republics,  has 
precipitated  incredible  changes  in  the  entire  worid  and  in  our  requirements  for  miiitary  capability. 
Some  of  these  changes  include  fBossert,  1990:3  -  4]: 

•  Increased  importance  of  convendonal  farces.  The  end  of  the  cold  war  has  brought  greater 
willingness  to  reduce  nuclear  wesson  stockpiles.  A  decrease  in  the  deterrence  value  of 
nuclear  weapons  makes  a  strong  conventional  capability  more  important 

•  ftoliferation  of  third  worid  "hot  spots”.  The  number  and  intensity  of  ongoing  or  potential 
conflicts  throughout  the  world  will  continue  to  grow  as  regions  adjust  to  the  vacuum 
createc-  hy  the  decline  of  Soviet  influence. 

•  Reduction  of  overseas  bases .  The  economic  and  budgetary  challenges  of  the  U.S.,  the 
increasing  reluctance  of  Americans  to  frmd  the  defense  of  Europe  and  Japan,  the 
widespread  perception  of  a  decrease  in  the  threat  posed  bj'  the  former  Soviet  Union,  and 
the  increased  reluctance  of  our  allies  to  renew  basing  rights  will  almost  certainly  result  in  a 
decrease  in  the  number  and  size  of  oveiseas  bases. 

The  Strategic  Mobility  Triad.  All  of  these  changes  point  to  the  requirement  for  a  military 

force  that  is  small,  flexible,  and  more  mobile  than  ever  before.  The  U.S.  depends  uj^on  a  triad  of 
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mobility  c^abilities  to  project  forces  to  a  threatened  area  Each  leg  of  the  triad  -  airlift,  sealift 
and  prepositioning  -  has  unique  strengths  and  weaknesses  that,  when  properly  balanced,  can 
provide  the  projectimi  equability  necessary  for  each  stage  of  a  conflict  (Hgure  1).  Airlift  is  the 
fastest  and  most  flexible  leg  of  the  triad,  but  it  is  veiy  limited  in  capacity.  In  Desert  Smeld,  for 
exanqile,  only  about  5  percent  of  the  total  cargo  was  delivered  by  air  [Conduct  of  Persian  Gulf 
War,  1992:E  -  9].  Rrepositioning  is  an  attractive  option  when  the  location  of  the  next  cinflict  can 
be  accurately  forecast  but  is  of  limited  value  otherwise  [Miller,  1988:373].  Sealift  can  move  huge 
quantities  of  materials,  but  it  is  slow.  Experts  estimate  that  sealift  to  some  regions  of  the  worid 
may  take  as  long  as  30  to  40  days  which  can  more  than  offset  the  advantage  in  capacity 
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Figure  1.  Balanced  Mobility  (Adapted  from  Miller,  1988:  366) 


(King,  1989:1].  As  an  example,  die  first  American  cargo  stup  that  arrived  in  Israel  during  die 
1973  Mid  East  war  delivered  more  tonnage  than  was  delivered  by  airlift  in  the  previous  30  days. 
However,  the  war  bad  been  over  for  20  days  [Conqitroller  General,  1 975 ]. 

The  AuM  Planning  System.  Airlift  provides  the  critical  projecdoti  capability  in  die  first  few 
days  of  a  conflict;  usually  before  a  clear  plan  of  action  has  been  determined.  Consequently,  an 
airlift  planning  system  must  be  flexiUe  enough  to  handle  daily  or  even  houriy  changes  in 
movement  requirements  and  priorities.  Air  Force  regulation  28-3  defines  the  Joint  Operational 
Hanning  and  Execution  System  (70PES)  as  the  single,  integrated  system  for  joint  planning 
within  die  Dqiaitment  of  Defense  (Hgure  2).  JOPES  provides  an  automated  system  for  use  in 
both  deliberate  and  execution  planning. 

Deliberate  planning  is  the  process  of  developing  Concept  Plans  (CCH^RANS)  and 
Operation  Plans  (OPLANS)  to  siqipoft  national  security  policy.  OPLANS  anddieir 
acconqianying  Time-Phased  Force  and  Deploymem  Data  (TPFDD  or  “tip-fid”)  are  developed  in 
antkqiation  of  a  future  airlift  operation.  The  OPLAN  describes  the  aircraft,  airfield  and  other 
resources  assigned  to  support  an  airiiftoperatioa  The  TPFDD  contains  deployment  data, 
including  on-*.oad  and  off-load  airfields,  and  the  type  and  amount  of  cargo  and  personnel  to  be 
deployed.  ConcqK  Plans  provide  the  flexibility  and  npd  reaction  needed  during  contingency 
situations.  CC^PLANS  do  not  have  corresponding  TPFDDs,  but  contain  a  summary  of  the 
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Figure  2.  Airlift  Planning  System 


most  likely  moMity  and  logistic  assets  needed  to  support  the  execution  of  a  plan.  The 
information  availaUe  at  the  time  of  deliberate  planning  is  necessarily  roug^  and  incomplete. 
Consequently,  the  goal  of  deliberate  planning  is  not  to  produce  a  detailed  schedule  of  operations 
but  only  to  provide  a  starting  point  for  executitm  planning  [Rappqptxt  et  al.,  1992:75; 

Rappoport  et  al.,  1 991 :64]. 

Execution  planning  is  conducted  in  response  to  an  actual  airlift  requirement  -  such  as  an 
exercise,  contingency,  or  humanitarian  relief  effort  A  very  powerful  tool  is  required  to  match  the 
individual  airlift  requirements  with  aircraft  and  crews,  and  then  to  schedule  individual  missions  to 
perfonn  the  airlift.  Normally,  enou^  information  is  available  during  execution  planning  to 
schedule  several  days  in  advance,  but  the  schedule  roust  be  continuously  adjusted  so  as  to 
account  for  changing  requirements  and  resources  [Rappoport  et  al.,  1992:75]. 

Lessons  Svm  Desert  Shield  One  of  the  most  important  lessons  learned  from  the  Persian 
Gulf  conflict  was  the  importaiKe  of  sound  planning  in  the  employment  of  strategic  lift  assets 
(airlift  and  sealift)  [Conduct  of  the  Persian  Gulf  War,  1992:xxiv].  While  advaiKe  planning 
played  an  important  role  in  the  overall  success  of  the  U.S.  response,  airlift  planners  were  largely 
unaUe  to  adapt  existing  plans  to  the  rapidly  changing  situation  in  the  time  required.  According  to 
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Major  Bruce  Babb,  a  member  of  the  Military  Airlift  Command  (MAC)  Crisis  Action  Team  during 
Desert  Shield,  the  planning  systems  and  mediods  in  use  in  August  1990  were  not  flexible  enough 
to  handle  the  airlift  requirements  of  operation  Desert  Shield.  “Tlie  primides  kept  changing  - 
sometimes  six  times  a  day  -  while  tire  deployment  flow  was  going  on.”  [Babb,  1990:1].  JOPES 
was  unable  to  cope  with  the  ccxistant  changes  in  a,rlift  requirements.  Just  sorting  out  the 
requirements  and  priorities  of  the  massive  airlift  fn*  iiqtut  to  the  system  could  have  delayed  the 
first  airlift  mission  by  weeks  or  even  mmths.  Since  even  a  week’s  delay  was  unacceptable,  the 
MAC  planners  were  forced  to  abandon  use  of  much  of  JOPES  and  manually  control  the  flow  of 
aircraft  [Babb,  1990:1  -  3]. 

In  addition,  deployment  data  had  not  been  reviewed  to  determine  transportation  feasit^ty. 

A  transpmtation  feasil^ty  study  determines  the  assets  needed  to  move  the  personnel  and 
equipmem  of  a  specific  military  unit  Rtpd  response  units  were  the  only  mes  for  which  current 
transportation  feasit^ty  data  was  available.  As  a  result  transportation  planners  were  forced  to 
improvise,  and  airlift  requirements  exceeded  ctqrability  by  as  much  as  7,000  tons  per  day 
[Conduct  of  the  Persian  Gulf  War,  1992:E  -  3;  Babb,  1990:2]. 

TbeDevdepmentofADANS.  The  weaknesses  in  JOPES  were  identified  long  before 
Desert  Shield  highli^ited  them.  Development  of  a  system  to  augment  JOPES,  called  the  Airlift 
Deployment  Analysis  System  (ADANSX  was  started  in  1987.  ADANS  is  an  interactive  database 
system  with  an  array  of  tools  which  can  be  used  to  perform  both  deliberate  and  executicHi 
planning  on  a  large  scale.  The  centerpiece  of  ADANS’  automated  scheduling  tools  is  a  dynamic 
programming-based  algorithm  called  the  airlift-planning  heuristic  (APH)  [Hilliard  et  al., 
1992:135].  The  objective  of  APH  is  to  develop  an  airiift  schedule  that  maximizes  the  on-time 
delivery  of  cargo  and  passengers .  The  APH  is  a  very  powerful  tool  and  is  capable  of  scheduling 
10,(XX)  missions  in  under  two  hours  [Rappoport  et  al.,  1992: 86]. 

ADANS  was  under  developmem  when  Desert  Shield  started,  and  the  program  was 
accelerated  to  help  cqre  with  the  inadequacies  of  the  JOPES  system.  Because  of  its  rushed 
inqrlementation,  no  performance  cotnparisrai  of  ADANS  to  JOPES  was  made,  but  there  is  little 
doubt  that  it  cmitributed  significantly  to  the  success  of  the  nearly  $4  billion  airlift  qreration 
[Hilliard  et  aL,  1992:140]  However,  development  of  the  deliberate  planning  tools  within 
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ADANS  was  delayed  in  favor  of  the  development  of  the  execudon  planning  tools,  such  as  the 
APH,  urgently  needed  for  Desert  Shield.  Consequently,  many  tools  are  still  under  development 
and  die  ADANS  system  as  a  whole  is  not  e}q)ected  to  reach  inidal  operadonal  capability  until 
March  1993  [MltcheU,  1992], 

Ihe  Airlift  C^abilides  Esdmadon  Prototype  (ACEP)  model  was  developed  by  Busch  and 
IfiUiard  of  the  Operations  Research  Group,  Oak  Rid^  National  Laboratory,  as  part  of  ADANS  to 
support  deliberate  planning.  It  is  a  linear  programming-based  tool  designed  to  provide  quick 
estimates  of  the  resources  needed  to  support  an  airlift  operation  [Busch  and  Hilliard,  1992:1]. 
ACEP  is  designed  to  be  fast,  flexible,  and  wotk  with  the  rough  information  that  is  available 
during  deliberate  planning  or  the  early  stages  of  execution  planning.  The  model  has  the  potential 
to  address  the  problems  encountered  in  the  early  days  of  Desert  Shield,  but  a  formal  analysis  is 
required  to  verify  that  the  model  is  accurate  enough  to  be  of  practical  use. 

Research  Otqecdves 

Ihe  ACEP  model  was  developed  in  response  to  a  demonstrated  need  for  a  tool  to  provide 
quick  estimates  of  the  resources  required  to  siq)port  a  planned  airlift  operation.  However,  this 
model  has  not  been  validated  to  ensure  that  it  adequately  represents  the  airlift  planning  problem. 
The  purpose  of  this  effort  is  to  validate  the  ACEP  model  and  to  improve  the  model,  if  possible, 
based  upon  the  validation  findings.  Specifically,  two  main  problems  are  addressed  by  this 
research:  . . 

(1)  How  to  independently  evaluate  the  valitfity  of  an  existing  model. 

(2)  How  to  improve  the  ACEP  model  to  better  meet  the  needs  of  Air  Mobility  Command  in 
solving  their  aidift  planning  problems. 

The  focus  of  the  first  part  of  the  research  is  cm  the  validation  of  mathematical  models.  While 
the  validation  methodology  developed  is  demonstrated  using  a  linear  programming-based  model, 
the  general  tqrproach  is  q)plicable  to  other  forms  of  models  as  well  (e.g.  nonlinear  models, 
simulation  models,  etc.).  The  goal  of  this  research  is  to  develop  and  demonstrate  a  structured, 
methodical  approach  to  the  validation  of  existing  models. 


The  focus  of  the  second  part  of  the  research  is  to  address  questions  presented  by  R.D. 
Specht  in  his  discussion  on  model  testing  in  “The  Nature  of  Models”  [Specht,  1968:220]; 

(1)  Cw  the  ACEP  model  describe  conectly  and  cleariy  the  known  facts  and  situations? 

(2)  When  the  principal  parameters  involved  are  varied,  do  the  results  remain  ctmsistent  and 
plausiNe? 

(3)  Can  die  ACEP  model  handle  special  cases  in  which  diere  is  some  indication  as  to  what 
die  outcomes  should  be? 

(4)  Can  it  assign  causes  to  known  effects? 


Ovemew  of  Subsequent  Chapters 

Cluqiter  II  contains  a  summary  of  published  literature  on  vehicle  routing  and  scheduling 
proUems  and  a  review  of  techniques  commonly  used  in  qieradons  research  to  validate  models. 

In  addidrai,  a  review  of  validation  techniques  in  software  engineering  is  presented  and  the 
qiplicability  of  diese  techniques  to  mathematical  model  validation  is  discussed. 

Charter  m  presents  a  model  development  life  cycle  and  the  results  of  applying  the  first  two 
stagra  of  the  life  cycle  to  the  ACEP  model  A  recovery  process  is  used  to  reconstruct  the  life 
cycle  stages  that  led  to  the  existing  model  design.  Some  significant  improvements  are  made  to  the 
model  as  a  result  of  the  life  cycle  lecov^  process. 


In  Chapter  IV,  the  (Rational  (executable)  version  of  ACEP  is  presented.  The  techniques  of 
constraint  validation  are  u^  to  ensure  the  model  accurately  represents  the  conceptual  ACEP 
model  design.  Again,  itrq^ovements  are  made  to  the  model  design  as  a  result  of  tire  craistraint 
validatitm  process.  1 

Cluqrter  V  presents  the  results  of  the  specific  post-development  validation  technique 
errqrloyed.  A  retrospective  ^  predictive)  test  is  conducted  using  data  fixnn  Operation  Desert 
Shield.  The  test  proved  to  b|  hi^y  useful  in  providing  insights  into  the  model’s  validity  for  use 
in  planning  and  executing  sustained  airlift  operations. 


Clupter  VI  concludes  the  research  and  provides  recommendations  for  further  research. 
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II.  Literature  Review 


The  airlift  planning  problem  can  be  thought  of  as  a  vehicle  routing  problem  (VRP)  with 
both  time  and  capacity  constraints  [Rappoport  et  al.,  1992:74].  In  the  first  part  of  this  chapter, 
an  overview  of  the  VRP  is  presented  including  classification  schemes  and  solution  qjproaches. 
The  second  part  of  the  chapter  reviews  verification  and  validation  techniques  used  on  both 
mathematical  models  and  computer  software.  Useftil  parallels  are  drawn  to  aid  in  die  validation 
of  the  ACEP  model. 

Vehicle  Routing  and  Scheduling  Problems 

Hie  costs  associated  with  operating  vehicles  and  crews  for  delivery  purposes  form 
an  important  conqionent  of  total  distribution  costs.  Craisequently  small  percentage 
savings  in  these  eiqienses  could  result  in  substantial  total  savings  over  a  number  of 
years . . .  The  use  of  analytic  routing  and  scheduling  models  inid  techniques  can  be 
instrumental  in  realizing  the  savings . . .  [Bodin  et  al.,  1983:70] 

fti  general,  a  VRP  can  be  defined  as:  A  set  of  customers,  each  with  a  known  location  and 
a  known  requirement  for  some  commodity,  is  to  be  siqiplied  from  a  set  of  (tepots  by  a  set  of 
delivery  vehicles.  Instantiations  of  the  VRP  vary  widely,  and  may  differ  in  the  number  of 
vehicles,  customers  and  depots.  Most  practical  VRPs  also  contain  some  time  and  capacity 
ctHistraints.  In  the  case  of  a  single  vehicle  with  unlimited  capacity,  the  problem  reduces  to  the 
well-known  traveling  salesman  problem.  The  objective  of  modeling  VRPS  is  to  develop  an 
“optimal”  route  or  schedule  for  each  vehicle.  Bodin,  Golden,  Assad  and  Ball  give  an 
overview  of  vehicle  routing  problems  in  a  special  1983  edition  of  Congjuters  and  Operations 
Reseaah  [Bodin  etaL,  1983]. 

ClassiScatiat  of  VRPs.  Several  classification  schemes  for  VRPs  have  been  proposed. 
Bodin  et  al.  provide  a  classification  of  VRft  into  three  groups:  (1)  pure  routing,  (2)  pure 
scheduling,  and  (3)  a  combination  of  both  routing  and  scheduling.  These  groups  are  then 
subdivided  into  a  more  detailed  classification. 
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More  recently,  Desrochers,  Lenstra  and  Savelsber^  developed  a  classification  scheme 
based  upon  the  various  constraints  added  to  the  basic  problem  [Desiochers  et  al.,  1990].  Their 
scheme  classifies  VRPs  based  iqron  the  characteristics  of  tihe  customers,  die  vehicles,  the 
service  strategies  enqiloyed,  and  the  ot^'ective  of  the  model 

In  many  cases,  customers  can  only  be  serviced  during  specified  time  windows.  Solomon 
and  Desrosiers  classify  the  different  types  of  VRI^  with  time  windows  by  die  underlying 
mathemadcal  model  that  most  closely  matches  the  problem  [Solomon  and  Desrosiers,  1988]. 
They  define  eight  classes  of  problems.  The  difficulty  with  this  approach  is  that  one  must  be 
aUe  to  determine  die  underlying  mathemadcal  model  from  the  problem  description.  However, 
once  the  undeilying  model  is  determined,  it  can  lead  direcdy  to  a  set  of  published  solution 
algorithms. 

Soludon  Approaches  to  VRR.  As  noted  in  the  opening  paragr^h  of  this  section,  VRPs 
are  among  the  most  rewarding  (and  difficult)  of  all  problems  to  solve,  and  much  has  been 
published  in  recent  years  on  solution  techtnques.  Ronen  identified  four  common  approaches  to 
solving  vehicle  touting  problems  -  manual  pure  qitimization  (exact),  optimization  with 
embedded  heuristics,  and  pure  heuristics  [Rtxien,  1988:141  ].  Because  the  manual  and  pure 
heuristic  qiproaches  depend  heavily  on  die  specific  triplication,  the  analysts  who  use  these 
approaches  do  not  normally  publish  their  weak  in  technical  journals.  Consequendy  most  of  the 
literature  deals  widi  die  “exacr  and  “optimization  with  embedded  heuristics”  approaches. 

Optimal  solutions  can  be  found  to  small  problems  by  using  direct  tree  search  methods, 
dynamic  programming,  or  integer  programming  [Laporte,  1992:346].  Unfortunately,  the 
largest  problem  that  can  be  solved  using  these  methods  is  still  quite  small.  Most  routing  and 
scheduling  problems  of  interest  are  NP-hard.  NP-hard  problems  are  a  class  of  network  and 
combinatorial  problems  fin*  which  no  polynomially-bounded  solution  algorithm  has  yet  been 
found  (a  polynomially-bounded  algorithm  is  one  whose  computational  burden  increases  only 
polynomially  in  the  worst  case  as  the  problem  size  increases ).  Because  the  VRP  class  of 
problems  is  NP-hard,  they  become  difficult  to  solve  as  the  number  of  vehicles  and  customers 
increases,  so  exact  soluticxi  approaches  can  only  be  used  on  small,  simple  problems.  The 
largest  vehicle  routing  problem  with  time  windows  solved  using  exact  methods  until  recendy 
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involved  only  4  vehicles  and  14  customers.  However,  recent  progress  has  increased  the  size  of 
solvable  problems  to  about  100  customers  by  decomposing  the  problem  and  using  a 
combination  of  exact  methods  [Desrochers  et  al.,  1 992:342], 

Most  problems  of  practical  size  are  solved  using  heuristics  or  by  a  combination  of 
qttimizaticHi  and  heuristic  methods.  “A  heuristic  algorithm  is  a  procedure  that  uses  the  problem 
structure  in  a  matiiematical  (and  usually  intuitive)  way  to  provide  feasible  or  near-optimal 
solutitHis”  [Bodin  et  al.,  1983:77].  A  heuristic  is  considered  eitfective  if  the  solutions  it 
provides  are  consistently  close  to  optimal  Most  VRP  heuristics  M  into  three  broad  categories 
-  tour  constmction  procedures,  tour  inqtrovement  procedures,  and  cotiq)osite  procedures 
[Bodin  et  al.,  1983: 87].  Linear  programming  (LP)  can  also  be  thou^t  of  as  a  heuristic 
algorithm  for  VRPs.  Relaxation  of  the  requirement  for  an  integer  solution  greatly  increases  the 
size  of  the  problems  that  can  be  solved.  However,  the  resulting  non-integer  solutions  may  have 
very  limited  meaning  and  may  not  resemUe  the  optimal  integer  solution  very  closely. 

Heuristics  are  used  extensively  to  solve  real-world  problems  because  of  the  limitations  of 
exact  methods,  but  their  performance  depends  heavily  upon  the  particular  ^plicatioa  While 
heuristics  generally  provide  a  “good”  feasible  solution,  it  is  often  difficult  to  determine  how 
close  the  heuristic  solution  is  to  tire  optimal  solutioa  Consequently,  the  exact  methods  are 
preferred  when  the  problem  is  small  enou^  that  an  qrtimal  solution  can  be  found  in  a 
reascmable  amount  of  time. 

Application  to  the  ACEP Model.  Since  the  ACEP  model  represents  an  instantiation  of  a 
potentially  large  vehicle  routing  problem,  a  heuristic  technique  for  obtaining  a  solution  appears 
to  be  the  best  alternative.  The  ACEP  model  developed  by  Busch  and  Hilliard  can  be  considered 
a  heuristic  solution  method  for  two  reasons: 

(1)  linear  programming  is  used  as  a  method  of  obtaining  an  optimal  solution,  but  the 
resulting  solution  contains  non-integer  values  and  is  not  feasible  without  further 
processing.  This  may  prove  to  be  adequate  rally  if  very  aggregate  results  are  required, 

(2)  The  computationally  difficult  problem  of  determining  the  optimal  routing  for  each 
aircraft  is  largely  avoided  by  including  only  the  most  practical  routes.  This  is 
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acceptatde  in  an  aiiliit  situation  where  cmly  a  very  limited  number  of  airfields  are 
availaUe  and  the  routes  can  be  easily  enumerated 

Certainly  other  heuristic  algorithms  could  be  developed  that  would  provide  feasible  (i.e. 
integer)  solutions.  One  goal  of  the  validation  process  is  to  determine  whether  or  not  the 
heuristic  technique  chosen  is  adequate.  For  this  reason,  it  is  inq)oirtant  to  validate  any  VRP 
formuladcm  before  using  the  model  to  support  routing  and  scheduling  decisions.  The  next 
section  provides  an  overview  of  verification  and  validation  techniques  commonly  used  in  both 
operatitxis  research  arid  software  engineering. 

Vaificadoa  and  Validation  Tecbniqiies 

Clayton  Thomas,  a  former  Chief  Scientist  of  the  Air  Force,  once  said  that  “all  models  are 
wrong,  some  are  useful”.  Models  are  wrong  because  they  are  an  inexact  representation  of 
some  real-world  system  cr  problem.  Determining  whether  or  not  a  model  is  “useful”  is  the 
goal  of  the  validation  process.  The  requirement  to  validate  models  is  common  to  all 
engineering  activities,  but  has  received  remarkably  little  attention  in  most  fields  of  engmeering. 
However,  a  relatively  mature  validation  paradigm  (model)  has  developed  in  the  field  of 
software  engineering  over  the  last  decade.  This  paradigm  can  be  applied  to  model  development 
as  well 

Conqmter Software  Validation.  The  development  of  mathematical  models  and  the 
development  of  software  systems  have  many  parallels.  Both  represent  an  abstraction  of  a  real 
system  or  probletiL  Much  pro^  ess  has  been  made  in  recent  years  in  developing  a  structured 
method  for  tiie  verification  and  validation  (V  &  V)  of  computer  software.  This  progress  was 
made  possible  largely  as  a  result  of  the  recognition  of  the  “life  cycle”  process  of  software 
development. 

Die  classic  software  development  life  cycle  is  presented  in  Hgure  3.  The  output  of  each 
phase  becomes  the  irqiut  to  the  next;  and  the  development  process  becomes  a  controlled 
transformatiOT  of  the  system  requirements  to  software  design,  to  software  modules  (computer 
code),  and  finally  to  an  executable  system.  Diis  life  cycle,  also  called  the  “waterfall”  life  cycle, 
developed  as  a  natural  consequeiKe  of  the  need  to  control  the  transformation  of  the  user’s 


11 


Figure  3.  Classic  Software  Life  Cycle  Paradigm 

requirements  for  the  system  into  executable  computer  code.  At  each  stage  of  the  process, 
{q)proximadons  and  sinq)lifying  assumptions  are  made  in  order  to  “model”  the  previous  stage. 
Consequently,  flaws  can  be  introduced  at  each  stage  which  will  cascade  through  the  subsequent 
stages  if  no  attempt  is  made  to  find  and  correct  them  These  flaws  M  into  two  general 
categories  -  errors  made  in  defining  the  requirements  for  the  system,  and  errors  introduced  in 
transforming  the  system  from  one  stage  to  the  next  (e.g.  transforming  written  requirements  into 
a  system  design).  Validatiao  is  then  defined  to  be  the  process  of  idendf^g  and  correcting  the 
first  type  of  error  -  errtKs  in  the  requirements,  and  ven£cation  is  the  process  of  ensuring  each 
transformation  from  one  stage  to  the  next  is  conecL 

Historically,  the  primary  method  of  performing  software  V  &  V  has  been  post- 
develqrment  testing.  Testing  is  the  process  of  identifying  discrepancies  between  actual  results 
and  expected  results  [ftinciples  of  Testing,  1985:3-1  J.  Since  discrepancies  (flaws)  may  be 
introduced  at  each  stage  of  the  life  cycle  process,  V  &  V  techniques  must  be  able  to  find  the 
flaws  and  identify  the  stage  where  each  flaw  was  introduced.  The  primary  disadvantage  to 
post-development  testing  (testing  after  the  system  is  built)  is  that  flaws  introduced  early  in  the 
life  cycle  cascade  throu^  subsequent  stages  and  become  difGcult  and  expensive  to  find  and 
correct  For  example,  a  flaw  made  in  defining  the  user’s  requirements  for  a  system  can  be  60  to 
100  times  more  costly  to  correct  after  the  system  is  built  than  during  the  requirements  analysis 
stage  [Pressman,  1987:17]. 

In  recent  years  a  more  structured  approach  to  software  validation  has  been  developed. 

More  emphasis  is  placed  on  the  early  stages,  especially  the  analysis  of  requirements.  Testing  is 
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perfonroed  after  each  stage  of  the  life  cycle  to  verify  and  validate  the  results  befote  continuing  to 
die  next  stage.  In  this  way,  the  most  difficult  and  costly  flaws  (the  flaws  introduced  in  the 
early  stages  -  such  as  the  requirements  analysis)  are  identified  and  corrected  before  they  can 
effect  subsequent  stages.  The  transfcrmafion  of  one  stage  to  the  next  is  furthei  controlled 
throu^  documentation  of  the  process  (Hgute  4). 


Figure  4.  Software  Life  Cycle  Documents  (Pressman,  1987:18) 


A  pierequisite  to  finding  flaws  in  system  requirements  is  to  obtain  a  written  **requirements 
specification”  which  acts  as  a  contract  between  the  software  developer  and  the  software  user. 
This  specification  defines  the  scope  of  the  software  system  for  the  developer  and  helps  define 
the  boundaries  of  die  system.  It  also  defines  the  major  fiinctioas  and  output  expected  of  the 
system,  helping  the  user  realize  the  sy^m’s  capabilities  and  limitations  before  it  is  built  The 
requirements  specification  is  written  at  the  user’s  level  without  software  engineering  jargon 
which  mi^t  obscure  the  intent  [General  Electric,  1986:4-7] 

After  the  requirements  specification  is  completed  and  approved  by  the  user,  a  system  is 
designed  to  meet  the  specifications.  The  design  is  documented  so  that  it  may  be  verified  against 
the  requirements  specification.  Computer  code  is  then  written  to  implement  the  approved 
design.  The  final  stage  of  testing  is  performed  by  the  user  of  the  system  and  is  designed 
primarily  to  find  any  flaws  in  the  specification  that  may  still  remain.  Thus,  the  cornerstone  of 
die  validation  process  is  the  requirements  specification.  Another  technique  which  has  gained 
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favor  in  recent  years,  and  is  made  possible  by  the  life  cycle  process,  is  the  concept  of 
independent  testing. 

Most  operational  modeling  is  performed  by  a  team  of  one  or  more  analysts  who  develop 
die  model  formulation,  implement  the  model,  and  validate  the  results.  For  many  years,  this  is 
how  most  conqiuter  software  was  developed  as  well.  Recently,  however,  many  software 
engineering  organizations  have  formed  independent  test  teams.  “Independent  testing  is  a  cost- 
effective  technique  fm'  finding  flaws  in  software,  and  it  is  evolving  as  the  standard  method  for 
verifying  production  application  software”  [ftinciples  of  Testing,  1985:4-5].  There  are  many 
benefits  to  performing  independent  testing  [Principles  of  Testing,  1985:4-6]: 

•  The  testing  is  conducted  by  personnel  who  have  not  been  involved  in  the  development  of 
the  software  and  can  be  more  objective  about  the  product  and  more  aggressive  in  finding 
flaws. 

•  Requirements  are  reviewed  from  a  different  perspective,  providing  a  valuable  double 
check  m  the  developer’s  interpretation. 

•  A  separate  test  team  is  likely  to  be  more  critical  m  its  interpretation  of  test  results. 

Li  summary,  two  important  techniques  can  be  borrowed  from  software  engineering  in 

performing  validation  tests  on  a  mathematical  model. 

(1 )  A  life  cycle  approach  to  model  develqnnent  may  help  guide  the  transformation  of  the 
user’s  requirements  into  a  valid  model. 

(2)  Hnal  validation  testing  should  be  performed  independently  of  model  development 
whenever  possible. 

Unfortunately,  the  disciplined  and  widely  accepted  validation  paradigm  of  the  software 
engineering  world  has  no  parallel  in  the  modeling  world.  Instead,  a  hodgepodge  of  post¬ 
development  validation  techniques  are  used  depending  upon  ti)e  model  form  and  the  specific 
tqrplication.  Consequently,  the  validation  of  models  can  be  a  more  difficult  task. 

Mathematical  Model  Validation  A  model,  like  computer  software,  is  an  abstract 
representation  of  some  real-world  problem,  i^proximations  and  simplifying  assun^ons  are 
generally  required  to  make  the  model  tractable  (ctqrable  of  being  solved).  Model  validation  can 
be  defined  as  the  analytic  process  of  proving  that  a  model  adequately  represents  the  problem. 
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and  that  a  solution  to  the  model  is  also  a  solution  to  the  real-world  problem.  Hillier  and 
lieberman  judge  the  validity  of  a  mathematical  model  1^  “whether  or  not  the  model  predicts  the 
relative  effects  of  the  alternative  courses  of  action  with  sufficient  accuracy  to  permit  sound 
decisions”  [Hillier  and  lieberman,  1 986:20]. 

The  development  of  laige  mathematical  models  requires  a  life  cycle  q)proach  similar  to 
software  engineering.  M  Model  BmldingmMatiiematicalRoffraiiiimng,  H.P. Williams 
describes  the  process  of  building  and  validating  a  model  as  “a  two-way  process  gradually 
converging  on  a  more  and  more  accurate  representation  of  the  situation  being  modelled” 
[Williams,  1985:96].  Figure  5  shows  penitqts  die  most  widely  used  model  development  life 
cycle.  A  Conceptual  Model  is  the  model  builder’s  understanding  of  the  important  parameters, 
processes  and  interactions  in  die  problem  or  system  to  be  modeled  [Alink  and  Blackstone, 

1992:  H-7].  An  Operational  Model  is  the  inqilementation  of  the  conceptual  model  into  an 
executable  form  [AUnk  and  Blackstone,  1992;  H-7].  A  Valid  Model  \s  an  operational  model 
that  has  been  proven  to  adequately  represent  the  problem  for  the  intended  use  of  the  model 


Only  recendy,  however,  has  serious  research  begun  on  many  of  the  issues  associated  with  the 
life  cycle  approach  to  modeling,  such  as  documentation  standards  and  configuration 
management 

Many  textbooks  on  operations  research  offer  suggestions  on  how  to  validate  mathiimarical 
models,  and  much  has  been  written  on  the  validation  of  other  types  of  models,  such  as 
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siniulation  models.  Most  ox  the  techniques  offered  are  post-development  tests  for  vali(Ut>’.  A 
survey  of  operations  research,  simulation,  and  expert  system  research  into  validation  yields  the 
following  techniques; 

(1)  Face  Validation.  This  technique  involves  havirig  potential  experts  and  people 
knowledgeable  in  the  domain  of  the  tq)plicadon  examiiie  the  model  in  action  and 
assess  its  performance  at  face  value  [O'Keefe  et  al.,  1 988:86]. 

(2)  Cor^aint  Validation.  In  many  linear  programming  models,  the  objective  function 
and  constraints  can  be  interchanged  to  provide  additional  insights  into  the  validity  of 
tiie  model  formulation.  “It  is  often  desirable  to  solve  the  model  a  number  of  times 
with  different  (possibly  contrived)  objectives  in  order  to  test  out  as  many  constraints 
as  possible”  [Williams,  1985:  96]. 

(3)  Predictive  or  retrospective  tests.  When  possible,  histmcal  data  can  be  used  as  irq)ut 
to  tile  model.  A  cottqiarison  of  the  model’s  solutitm  to  what  actually  happened  may 
indicate  whether  using  the  model  is  a  significant  improvement  over  current  practices. 
The  technique  is  best  described  by  Bazaraa,  Jarvis  and  Sherali  in  Linear  Programming 
and  Network  Flows  as  follows: 

Tiie  fourth  stage  [of  model  building]  is  model  testing,  analysis,  and  (possibly) 
restructuring  One  examines  the  model  solution  and  its  sensitivity  to  various 
system  parameters,  and  studies  its  predictions  to  various  what-if  types  of 
scenarios.  This  analysis  provides  insights  into  the  system.  One  can  also  use 
tins  analysis  to  ascertain  the  reliability  of  the  model  by  comparing  the  predicted 
outcomes  witii  the  expected  outcomes,  using  either  past  eiqierience  or 
conducting  the  test  retroactively  using  historicai  data.  [Bazaraa  et  al.,  1990:8] 

There  are  two  disadvantages  to  this  ^iproach.  First,  it  may  use  the  same  data  that 

guided  the  formulation  of  the  model  [Hillier  and  Lieberman,  1986:23].  Second,  the 

outcome  of  past  events  is  only  one  of  many  possible  outcomes,  and  it  is  unlikely  that 

a  model  can  incorporate  all  of  the  determining  factors  [Rritsker,  1986:13]. 

(4)  Event  validity  or  sensitivity  analysis.  Sensitivity  analysis  is  performed  by 
systematically  changing  the  input  parameters  over  some  range  of  interest  and 
observing  the  effect  upon  system  perfomiance  [O'Keefe  et  al.,  1 988:86]. 
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(5)  'niring  tests.  While  more  commonly  used  to  validate  e:q>en  systems,  Turing  tests  can 
be  used  to  validate  any  kind  of  model  designed  to  replace  a  previous  method.  Thetest 
is  conducted  by  providing  experts  with  ouq)ut  frtnn  both  the  modd  and  dw  previous 
method  without  knowing  the  origin  of  each  set  of  ouqNit  If  the  e:q)eits  cannot  tell  the 


<fi£Gerence,d)en  die  test  is  a  success.  The ’Siting  test  is  especially  helpful  in 
estabKriiing  the  validity  of  a  new  system  where  die  users  are  reluctant  or  skeptical 
(OlCeefeetal.,  1988:86]. 

(6)  Hddtsts.  As  a  last  resort  in  validadon  techniques,  the  model  can  be  placed  in 
operation  to  determine  how  well  it  performs.  Normally,  the  previous  method  of 

•  -a_  J_ 
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little  guidance  is 


obtaining  sdutions  continues  to  be  used  as  well  to  provide  m  additional  tool  for 
evaluation  [OlCeefe  et  al.,  1988:86]. 

These  validation  techniques  are  widely  used  by  andysts,  but  ve 
published  on  how  to  perform  each  technique  since  dieir  qiplication  is  U^y  proNem 
dependent  In  addition,  exh  of  the  techniques  is  a  post<devdopment  !test  for  validaticm  in  diat 
the  modd  must  be  created  before  they  can  be  used.  Thus  diese  techniques  are  only  really 
effective  idien  they  are  coiqiled  with  a  strong  life  cycle  devdopmem  qiproach. 

In  sununary,  a  review  of  die  literature  leads  to  three  conclusions  about  the  ACEP  model 
validation  problem.  Hrst  since  the  prodem  represenls  an  instantiation  of  a  large  vehicle 
routing  and  scheduling  prodem,  a  heuristic  technique  for  obtaining  a  solution  is  neces.saty. 

One  of  the  tasks  of  the  validation  process  is  to  determine  if  die  heuristic  technique  used  is 
adequate.  Second,  a  review  of  validation  techniques  in  both  software  engineering  and 
operations  research  inficate  that  validation  of  mathematical  models  may  be  best  acconqilished 
through  a  systematic  life  cycle  development  approach  coupled  with  post-developn»nt  validation 
tests.  And  finally,  diere  may  be  advantages  to  performing  the  validation  independendy  of 
model  development 

hi  the  next  cluqiter,  a  new  naxlel  development  life  cycle  is  proposed  and  applied  to  the 
ACEP  model  to  begin  die  validation  process. 
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nL  LJ&  Cycle  Validation  Approach 


The  model  validatirai  approach  used  on  the  ACE?  model  is  based  upon  the  validation 
paradigm  of  software  engineering  reviewed  in  the  previous  chapter.  A  disciplined  and  well 
documented  life  cycle  development  spproach  was  found  to  be  the  most  effective  way  to  validate  a 
model  In  dos  chq)ter,  a  model  development  life  cycle  is  proposed  and  qiplied  to  the  ACEP 
model  As  a  result,  significant  flaws  are  found  in  the  original  ACEP  design. 

The  first  step  in  foe  validation  process  is  to  define  a  general  model  development  life  cycle. 
The  difSculty  in  flying  a  life  cycle  validation  approach  to  the  ACEP  model  is  that  a  model 
design  has  already  been  proposed  while  no  formal  written  requirements  for  foe  model  are 
availaUe.  Thus,  foe  second  step  is  to  recover  the  undocumented  life  cycle  stages  already 
conq)leted  on  the  ACEP, 

Proposed  Model  Developmait  LUe  Cycle 

The  proposed  model  development  life  cycle  ctn  be  described  as  a  four  step  process  similar 
to  foe  classic  “waterfall”  life  cycle  used  in  software  development  (Figure  6).  Each  stage  is 
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Figure  6.  Proposed  Model  Development  Life  Cycle 
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dependent  upon  the  previous  stage  for  its  requisite  iiq)ut  The  feedback  lines  in  die  diagram 
indicate  dial  die  process  is  iterative.  When  a  flaw  is  discovered  in  one  stage,  die  process  is 
backtracked  to  the  stage  where  the  flaw  was  introduced  and  restarted.  Most  model  developers 
use  arougli  qiproximation  of  this  life  cycle  naturally.  However,  a  more  disciplined  use  of  the 
process  is  needed  to  develop  large,  conqilex  models  and  when  a  model  is  to  be  used  more  dian 
once.  In  addition,  formal  documentaticxi  of  each  stage  of  the  life  cycle  process  may  help  greatly 
in  the  use  and  maintenance  of  the  model 

Analysis  ofRequaemeiOs.  The  first  and  most  important  stage  of  the  model  development 
life  cycle  is  die  analysis  of  requirements.  Tlie  output  of  this  stage  is  a  formal,  written 
requirements  specification.  This  document  puts  in  writing  the  requirements  of  the  model 
including  a  description  of  die  problem  being  modeled,  the  eiqiected  inputs  to,  and  outputs  firom 
the  model  and  the  perfonnance  criteria  that  the  model  is  eiqiected  to  meet  The  content  of  this 
document  should  also  include  the  motivation  for  the  model  the  intended  use  of  the  model  and 
die  specific  post-development  steps  planned  to  validate  the  model  for  operational  use.  The 
requiremems  specification  ^ould  not  fin  thet^)  be  constrained  to  any  particular  modeling 
iqiproach  or  solutitm  mediodology,  except  where  the  users  of  the  model  are  constrained  by 
availaUe  modeling  resources.  A  typical  model  requirements  specification  might  include  the  items 
shown  in  figure  7. 


Modd  Requirements  SpcdBcatioa  (MRS) 

z: 

6.0  Model  Input 

Table  e^Coatents 

in 

7.0  ModeiOu^ut 

1.0  Overview 

— 

— 

8.0  Modd  Validation 

2.0  Applicable  Documenti 

— 

— 

8.1  Validation  Criteria 

3.0  PrcMem  Summaty 

— 

— 

8.2  Validation  Steps 

4.0  Modeling  Objective 

4.1  Ptimary  Optimiaation  Ooals 

4.2  Secondaiy  Optimization  Coab 

zz 

S.O  Modeling  Constraints 

— 

Ui 

— 

— 

iv 

Figure  7.  Model  Requirements  Specification  Format 


Model  Design  The  second  stage  is  to  transform  die  requirements  into  a  model  design  (die 
“conceptual  model”).  The  design  document  should  describe  the  modeling  tqiproach  taken  (e.g 
linear  programming),  the  assunqitions  required  to  use  the  modeling  ^preach  chosen,  and  the 
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model  design.  While  Data  Flow  Diagrams  and  Data  Dictionaries  have  become  the  standaixi 
design  tools  in  software  engineering,  no  such  standard  design  tool  has  emerged  in  modeling. 
Thus,  a  wide  variety  of  design  tools  can  be  used.  In  simulation  models,  for  example,  the  model 
design  migftt  be  represented  by  network  flow  diagrams.  In  mathematical  models  such  as  the 
ACEP  model,  the  design  is  most  often  represented  by  a  mathematical  formulation  conqnised  of 
parameters,  variables,  and  equations  which  relate  die  parameters  and  variables  to  each  other. 
Since  a  proposed  ACEP  formulation  already  exists,  the  design  document  in  this  case  e}q)ands 
upcHi  the  formulation  and  updates  the  model  based  upon  the  “recovered”  model  requirements. 
Figure  8  shows  the  format  of  the  design  document  used  for  ACEP. 


Model  Design  Document  (MOD)  — 

~  6.2  Modeling  Objective 

Table  of  Contents  — 

ZZ  6.2. 1  Decision  Variables 

1.0  Overview  ZZ 

~  6.2.2  Objective  Function 

2.0  Applicable  Documents  — 

—  6.3  Constraint  Equations 

3.0  Problem  Summary  “ 

—  6.4  Variable  Bounds 

4.0  Overview  of  Modeling  Approach  “ 

~  7.0  Model  Output 

5.0  Model  Assumptions  ZZ 

ZZ  7.1  Decision  Variables 

6.0  Mathematical  Formulation  ZZ 

—  7.2  Sensitivity  Information 

6. 1  Parameters  — 

—  8.0  VeriTication  Matrix 

iii  — 

—  iv 

Figure  8.  Model  Design  Document  Format 


Model  Lnplementatioa  The  third  stage  is  the  transformation  of  the  design  into  an  executable 
(or  “operational”)  model.  This  is  normally  done  with  a  mathematical  modeling  system  or  by 
writing  computer  code.  In  some  cases,  the  transformaticm  from  design  to  implementation  is 
automated.  In  any  case,  the  transformation  is  required  to  produce  a  model  which  generates  the 
desired  informatioa  The  main  validation  goal  of  this  stage  is  to  ensure  the  operational  model 
correctly  inqjlements  the  conceptual  model.  Each  constraint  is  examined  one  at  a  time  in  a  logical 
order.  The  effect  of  each  type  of  constraint  on  the  solution  of  a  contrived  set  of  input  data  is 
conqtared  with  what  is  expected,  and  any  discrepancies  are  investigated.  This  j[mx;ess  is  called 
corntraint  validation.  The  ACEP  design  was  implemented  using  the  General  Algebraic  Modeling 
System  (GAMS)  and  the  constraint  validation  process  used  to  verily  the  GAMS  model  is  outlined 
in  Chapter  IV. 


Oper^oaal  Validsdoa.  The  final  stage  in  this  transformation  is  a  post-development 
validation  process  to  ensure  the  executable  model  accurately  represents  the  problem,  meets  the 
performance  and  validation  criteria  outlined  in  the  requirements  specification,  and  is  suitable  for 
die  intended  use  of  the  model  This  process  can  be  caUed  “operational  validation”  [Alink  and 
Blackstone,  1992:  H-8].  Hie  retrospective  test  described  in  the  literature  review  is  used  in  this 
step  and  is  described  in  detail  in  Cluster  V. 

The  proposed  life  cycle  for  model  development  ofiers  two  major  advantages  over  the 
traditional  method  of  model  building.  First,  the  model  formulation  is  divided  into  two  distinct 
phases  -  analysis  of  requirements  and  model  design.  This  places  more  emphasis  on  the 
investigation  of  requirements  in  the  beriming  which  increases  the  chances  that  the  model 
develqied  will  be  adequate  for  its  intended  use.  Second,  the  results  of  each  stage  of 
develqiment  are  documented.  This  allows  for  a  “face  validation”  of  the  model  earlier  and  makes 
an  independent  evaluation  of  the  model’s  validity  possible. 

Clearly  this  proposed  life  cycle  has  merit  in  the  development  of  new  models.  However,  the 
ACEP  model  already  exists  in  a  conceptual  form.  The  next  section  describes  the  process  used  to 
apply  the  life  cycle  to  the  existing  ACEP  model  desiga 

Recovery  of  Model  Requnemeats 

The  ACEP  model  proposed  by  Busch  and  IfiUiard  describes  a  conceptual  model  design.  To 
recover  the  missing  life  cycle  stages,  tiiat  portion  of  the  normal  development  life  cycle  that  lies 
“upstream”  fix)m  the  existing  model  has  to  be  recreated.  In  the  case  of  the  ACEP  model,  the 
requirements  for  the  model  have  to  be  analyzed  and  a  written  specification  developed  before  the 
design  can  be  inq)lemented  (Figure  9).  Hiree  approaches  are  possiUe  in  reconstructing  model 
requiremerus:  starting  over,  “backing  in”,  or  a  combination  of  both. 

(1)  Starting  Ot'er.  The  existing  design  can  be  ignored  and  the  entire  life  cycle  process 
started  over.  Tire  advantage  to  tins  approach  is  that  any  modeling  ^rproach  can  be 
taken  and  great  improvements  in  the  final  model  are  possible.  This  approach  is  likely  to 
take  more  time  and  effort,  however,  and  ignores  the  contribution  of  previous  work  that 
was  performed  to  create  the  existing  design. 


(2)  Backing  In.  Using  a  variation  of  Meyer’s  “backing  in”  approach,  the  requirements 
q)ecification  can  be  created  to  lead  directly  to  the  existing  design  [Meyer,  1987].  The 
model  user’s  ^jproval  of  the  requirements  specification  “as  is”  then  represents 
compelling  evidence  that  the  existing  design  is  adequate.  Similarly,  changes  to  the 
specification  requested  by  the  model  user  should  lead  directly  to  improvements  in  the 
design.  This  ^)proach  might  be  the  best  alternative  when  the  requirements  are  not  well 
understood,  when  the  existing  design  is  likely  to  be  adequate,  or  when  time  and  effort 
constraints  are  imposed  that  prevent  a  complete  rework  of  the  model. 

(3)  Combination  of  both  tq)proaches.  A  comUnation  of  approaches  can  be  used  when  some 
requirement  changes  are  known  ahead  of  time.  This  q)proach  was  used  to  recover  the 
requirements  for  the  ACEP  model  Most  of  the  requirements  in  the  specification  were 
described  in  such  a  way  as  to  lead  more  or  less  to  the  representation  of  the  requirement 
used  in  the  model  design  C'backing  in”).  However,  some  additional  model 
requirements  were  evident  from  the  beginning  and  were  included  in  the  first  draft  of  the 
requirements. 

The  ACEP  Model  Requirements  Specification  (MRS),  contained  in  Appendix  A,  was 
developed  through  research  into  the  airlift  planning  problem,  analysis  of  the  ACEP  design,  and 


numerous  interviews  with  analysts  at  Air  Mobility  Command  Each  iteration  of  the  specification 
was  reviewed  by  die  model  sponsor  as  well  as  by  other  eiqierts  on  the  airlift  planning  problem, 
provitfing  a  valuaUe  “face  validation”  of  the  model’s  requirements. 

ACEP  Design  Changes 

Once  die  recovered  requirements  specificadon  was  approved  by  the  model  sponsor  at  Air 
Mobility  Command,  then  die  model  design  was  updated  to  reflect  the  new  requirements.  The 
ACEP  Model  Design  Document  (Appendix'S)  was  created  based  iqion  the  original  ACEP  design 
and  the  new  model  requirements.  Changes  to  the  design  which  resulted  fi-om  the  new  model 
requhements  include: 

(1)  Route  structure.  The  original  design  assumed  diat  the  off-load  airfield  was  the  last  stop 
on  each  route,  failing  to  account  for  the  return  of  the  aircraft  to  their  home  base.  A 
recovery  base  near  die  off-load  airfield  was  also  added  to  the  route  structure,  although 
diis  new  requiienient  did  not  effect  the  current  model  design  (see  Appendix  A,  Section 

5.3  for  a  more  detailed  description  of  the  route  structure). 

(2)  WoridngMOG.  The  original  design  included  flow  constraints  to  account  for  the 
available  ramp  ^ace  at  each  airfield.  However,  the  analysts  at  AMC  normaUy  work 
widi  two  different  Idnds  of  MOG  (maximum  on  the  ground)  in  planning  airlift 
operations  -  parking  M()G  which  accounts  for  ramp  space,  and  a  “working”  MOG 
which  accounts  for  other  factors  such  as  refueling  cr^ability  (see  Appendix  A,  Section 

5.4  for  a  moe  detailed  description  of  MOG). 

(3)  NfinimumloadrequiiemenL  The  new  design  includes  the  option  to  specify  a  lower 
bound  on  the  number  of  missions  scheduled,  preventing  the  model  firom  scheduling 
aircraft  witii  loads  below  a  certain  percentage  of  capacity  (see  Appendix  A,  Section  5.5) 

(4)  Aircraft  utilizaticKi  constraints.  The  utilization  of  airlift  aircraft  is  constrained  by  a 
number  of  factors  including  crew  limitations  and  maintenance  requirements.  Air  Force 
planners  aggregate  these  factors  into  a  utilization  rate  (called  UTE).  The  Busch  and 
Hilliard  fonnulation  of  ACEP  did  not  include  UTE  constraints,  but  UTE  was  included 
in  tile  requhements  at  the  request  of  the  model  sponsor.  The  aircraft  utilization 
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CfHistraints  required  additional  iiqjut  to  the  model  including  infomiation  on  the  expected 
fiig^  time  between  airfields  on  each  route,  the  expected  ground  time  at  exh  stq),  and 
the  objective  UTE  rate  for  each  aircraft  and  surge  perioo  ^see  i<^pendix  A,  Section  5  J). 

To  summarize,  the  proposed  model  developmem  life  cycle  offers  two  major  advantages  over 
die  traditional  model  development  paradigm:  (1)  more  enqihasis  is  placed  on  investigating  the 
needs  of  the  model  sponsor,  increasing  the  chances  that  the  model  developed  will  be  “useful”; 
and  (2)  the  transformation  of  the  model  through  each  stage  of  fee  life  cycle  process  is 
documented  to  help  in  fee  validation  process  as  well  as  in  the  use  and  maintenance  of  fee  model. 
Hiree  q)proaches  were  discussed  for  applying  fee  proposed  life  cycle  to  the  existing  ACEP 
model:  (1)  starting  over,  (2)  “baking  in”  to  fee  model  requirements;  and  (3)  a  combination  of 
(1)  and  (2).  The  combination  tpproach  was  used  to  improve  the  existing  design  of  the  ACEP 
model.  I 

In  the  next  ch^ter,  fee  process  used  to  build  and  validate  an  executable  version  of  fee  ACEP 
model  design  using  GAMS  is  discussed. 
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IV.  Consaaim  Validation 


The  recovery  of  model  requirements  provic^  a  valuable  tool  in  improving  the  Busch  and 
Ifilliard  ACEP  model  design.  The  third  stage  in  the  prq)osed  model  life  cycle  is  to  build  an 
operadtmal  model  that  inqilements  the  conceptual  model  design.  In  diis  chapter,  the  process  used 
to  build  an  executable  version  of  ACEP  using  die  GAMS  modeling  language  is  presented.  In 
addition,  constraint  validation  techniques  for  ensuring  die  operational  model  conectly  implements 
the  conceptual  model  design  are  discussed  Finally,  die  results  of  using  these  techniques  on  the 
ACEP  are  given. 


GAMS  Implementation 

GAMS  acts  as  a  “front-end”  and  a  “back-end”  to  a  solver  and  is  designed  to  make  the 
frarmulation  and  maintenance  of  large  and  complex  mathematical  models  easier  [Brooke  et  al., 
1988:  Rrefece].  The  GAMS  modeling  language  provides  an  impressive  array  of  tools  for 
manipulating  the  iigiut  parameters  as  well  as  the  solution  and  sensitivity  informatioa  Figure  10 
shows  the  process  GAMS  uses  to  obtain  a  solutitm  to  a  model.  A  special  interface  program  must 
be  written  to  pass  the  model  from  GAMS  to  a  solver,  but  interface  routines  for  the  most  widely 
used  solvers  are  available.  For  the  validation  tuns  of  the  ACEP  model,  the  MINOS  solver 
(Version  5.2,  March  1988)  was  used 
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Figure  10.  General  Algebraic  Modeling  System  (GAMS) 


The  GAMS  inqjlementation  of  ACEP,  provided  in  Appendix  C,  represents  yet  another  level 
of  abstraction  from  the  real  problem.  More  assumptions  and  iipproximadons  are  required  to 
inq)lement  the  model  formulatioa  Consequently,  the  next  step  after  building  the  operational 
model  is  to  verify  that  it  is  an  accurate  implementation  of  the  conceptual  model.  In  doing  so, 
frnther  insi^  into  the  model  and  the  problem  is  gained  providing  an  additional  tool  for 
validatioa  This  process  is  called  constraint  validation  and  has  three  main  goals: 

(1)  Verify  that  each  constraint  worics  -  that  the  mathematical  representation  of  each  resource 
is  correctly  inqtlemented  in  the  model. 

(2)  Ensure  that  the  representation  of  each  constrained  resource  does  not  cause  unexpected 
“side  effects”  that  result  in  unrealistic  model  solutions  when  the  constraint  is  enforced. 

(3)  I^ovide  further  insight  into  the  validity  of  the  model  requirements  and  design. 

The  process  of  constraint  validation  was  accomplished  in  three  primary  ways:  (1)  throu^  the 
development  of  a  contrived  airlift  scenario  designed  to  “stress”  the  model;  (2)  by  systematically 
adding  ccmstraints  to  a  skeletal  model;  and  (3)  by  examining  the  solution  to  alternative  objective 
functions. 

Contrived  Scenario  A  designed  set  of  input  data  is  necessary  to  initially  test  the  operational 
model  and  to  act  as  a  baseline  scenario  for  further  constraint  testing.  An  airlift  scenario  was 
designed  for  ACEP  to  make  each  constraint  binding  at  some  point  during  the  planning  horizon  of 
the  model  This  was  possible  because  of  the  multi-time  period  aspect  of  the  ACEP  model. 
Without  this  aspect,  many  different  scenarios  would  have  to  be  created  to  accomplish  the  same 
objective.  The  primary  resource  constraints  of  interest  in  the  ACEP  model  are; 

(1)  Airfields.  The  cxi-load  and  off-load  airfields  are  limited  in  the  amount  of  cargo  and 
passengers  that  can  be  processed  during  each  unit  of  time  (cargo  throughput  and 
passenger  throughput).  All  airfields  have  a  limited  amount  of  ramp  space  for  parking 
aircrafr  (parking  MOG).  In  addition,  airfields  may  have  limited  capability  to  service 
aircraft  (refuel  maintain,  etc.  -  called  wOTking  MOG).  See  Appendix  A,  Section  5.4 
for  a  complete  description  of  the  airfield  resource  constraints,  and  Appendix  B,  Section 
6.3.3  for  the  mathematical  formulation  of  the  constraints. 
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Figure  11.  Test  Scenario  Route  Structure 


(2)  Aircraft  A  Uimted  number  of  aircraft  are  available  at  any  given  time  and  the  utilization 
(UTE)  of  the  aircraft  (number  of  fli^t  hours  accumulated  over  a  given  period)  is 
limited.  See  Appendix  A,  Section  5.5,  and  Appendix  B,  Section  6.3.3  for  more  detail 
on  the  aircraft  resource  constraints. 

A  route  structure  was  designed  to  force  bottlenecks  in  the  system  (Figure  11).  Table  1  lists 
die  airfields  with  designed  shortages  in  constrained  resources  and  the  time  periods  in  the  model 
when  the  shortages  occur. 

TABLEl 

Designed  Scenario  -  Airfield  Bottlenecks 

Airfield  Resource  .Shortage  Time  Periods 

K003  Cargo  Throughput  (MHE)  COl  -  C05 

K()05  Pax  Throughput  (Pu  Terminal)  COl  -  COS 

K004  Woildng  MOG  (Fuel  trucks)  COl  -  C64 

_ _ K006 _ Parking  MOG  (Ramp  Space)  COl  -  C64 _ 

Tests  of  the  aircraft  resource  constraints  (availaixlity  and  utilization)  were  designed  by 
enforcing  low  surge  period  UTE  constraints  during  the  first  three  days  of  the  planning  period  and 
by  modifying  tire  penalty  for  using  an  aircraft  The  penalty  was  modified  to  increase  with  time, 
penalizing  any  delays  in  delivering  the  cargo  and  passengers  after  tire  stan  of  the  pickup  window. 
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This  forced  the  model  to  schedule  the  aircraft  at  the  maximum  utilization  and  availal^ty  early  in 
the  model  to  deliver  the  cargo  and  passengers  as  soon  as  possible. 

The  model  was  executed  with  the  test  scenario  data  using  the  primary  modeling  objective  of 
minimizing  shortfall  and  closure  (day  of  last  delivery).  The  results  showed  drat  each  of  the 
constraints  was  working  correctly  and  no  une:q)ected  “side  effects”  were  immediately  q)parenL 
However,  further  refinements  were  made  to  the  post-processing  of  the  solution  to  provide  more 
useful  informatioa  Ofparticular  interest  was  the  sensitivity  analysis.  While  this  information  can 
be  printed  automatically  by  GAMS,  the  sheer  volume  of  the  information  available  in  even  a  small 
scenario  is  overwhelming.  The  most  useful  sensitivity  infarmaticn)  was  the  marginal  value  of 
each  of  the  constrained  resources.  The  UP  solver  conqrutes  a  marginal  value  for  each  constraint 
equation  in  the  model.  To  aggregate  this  information,  post-processing  was  added  to  gather  (sum) 
the  margioal  cost  information  across  the  relevant  time  periods.  For  example.  Table  2  shows  the 
information  conqnited  on  airfield  MOG  used  in  the  q)timal  soludoa 


TABLE 2 


Designed  Scenario  -  MOG  Sensitivity  Information 


Maximum  Percent 

Accumulated 

Airfield 

of  Capacity  Used 

Marginal  Cost 

KOOl 

56.0% 

K002 

35.7% 

K003 

93.0% 

K004 

100.0% 

30.887 

K005 

51.7% 

K006 

100.0% 

11502 

The  table  shows  that  the  full  capacity  of  the  MOG  resource  was  used  at  both  airfield  K(X)4 

and  airfield  K006  as  expected.  In  addition,  the  marginal  cost  information  indicates  that  the 

\ 

I 

shortage  of  MOG  at  airfield  K004  has  a  larger  impact  on  the  solution  than  K(X)6.  In  fact,  a  one 
unit  increase  in  the  MOG  available  at  K004  across  the  entire  planning  period  will  improve  the 
objective  function  by  up  to  30.887  units.  The  actual  improvement  may  be  Iws,  however,  since 


die  aggregation  of  the  marginal  cost  across  the  planning  period  assumes  that  the  cunent  basis 
remains  optimal  after  the  change  (the  actual  improvement  in  this  case  was  21.8  because  the  basis 
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changes).  The  aggregate  marginal  cost  provides  a  good  way  of  determining  of  the 

constrained  resources  ofiets  die  most  potential  inptivement  in  the  otgective  function  adding  to 
die  availaMity  of  the  resource.  Cnee  a  good  cemtrived  scenario  has  been  designed  and  tested,  it 
can  be  used  in  a  more  detailed  analysis  of  each  of  the  model  constraints. 

CamahaExamimdai  The  designed  scenario  provides  a  good  initial  assessment  of  the 
qier^onal  model  The  next  step  is  to  perform  a  more  detailed  examination  of  each  of  the 
constrained  resources.  This  is  d(me  by  stripping  the  model  of  all  but  tte  most  basic  parameters 
and  equations  and  then  introducing  the  resource  consti'aints  one  at  a  time  to  observe  their 
individual  effects.  With  four  primary  types  of  constrained  resources  (the  number  and  utilizatiem 
of  aircraft,  and  tiie  airfield  MOG  and  througlqiut),  there  are  41  =  24  ways  in  which  these  four 
constraints  can  be  introduced  to  the  model  However,  there  are  lo^al  considerations  that  can  be 
used  to  eliminate  some  combinations.  For  example,  the  UTEconstrainls  in  the  ACEP  model 
cannot  be  conqiuted  without  providing  the  maximum  number  of  aircraft  available.  Unis  the  UTE 
emstraints  must  be  added  to  the  model  after  the  aircraft  availability  constraints.  In  tins  manner 
infeasible  combinations  can  be  eliminated  fixim  consideration  and  one  of  the  remaining 
combinations  chosen  to  begin  the  test 

The  basic  ACEP  model  includes  the  otgective  function  and  tiie  constraints  which  account  for 
die  delivery  or  shortfall  of  the  cargo  and  passengers  (DELIVPAX,  DEUVBLK,  and 
DELIVOUT).  In  addition,  tiie  NONPREF  constraints  are  included  in  tiie  basic  model  since  tiiey 
have  no  effect  on  resource  consumption  (see  Appendix  C).  Table  3  shows  tiie  order  in  which  the 
constraints  were  introduced  to  the  basic  model  and  the  effect  of  each  additional  constraint  on  the 
size  and  density  of  the  cmistraint  matrix  (percent  of  matrix  elements  that  are  nonzero). 

TABLES 

Constraint  Validation  -  Model  Size  and  Density 
(Objective  Function  -  Minimize  Cost) 


#  of  Constraints 

#  of  Variables 

Density _ 


Base 

MOG 

Thmput 

Axail 

IIIE 

72 

444 

684 

932 

944 

1740 

1740 

1740 

1740 

1740 

2.9% 

1.3% 

1.6% 

1.5% 

1.6% 
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The  MOG  equatioiis  represent  the  largest  block  of  constraints  (372),  but  are  also  the  least 
dense  -  a  significant  factor  in  the  effOTt  required  to  find  the  optimal  solutioa  Table  4  shows  the 
effect  of  each  constraint  on  the  q)tinial  solution. 

TABLE 4 


Cmstraint  Validation  -  Effects  rat  Solution 
(Objective  Function  -  Minimize  Cost) 


Solution  Characteristic 

MOG 

Thniput 

Avail 

HIE 

#  of  Iterations  * 

325 

273 

1335 

4209 

3618 

Objective  Functicni  Value 

1,497.17 

2,362.65 

2,514.74 

2,923.04 

3,336.43 

Latest  Delivery  Date 

Day  29 

Day  33 

Day  35 

Day  41 

Day  47 

Total#  of  Sorties 

197 

177 

177 

177 

177 

Sratie  Mixture  (Percent  of  Total  by  Aircraft  Type) 

C-141 

45.9% 

33.5% 

33J% 

33.5% 

33.5% 

C-5 

34.4% 

38.3% 

38.3% 

38.3% 

38.3% 

C-17 

11.2% 

12.4% 

12.4% 

12.4% 

12.4% 

P-747 

8.5% 

15.8% 

15.8% 

15.8% 

15.8% 

Cargo  Mixture  (Percent  of  total  deliveied) 

Out-  C-5 

100% 

100% 

100% 

100% 

100% 

Blk-  C-5 

75.4% 

75.4% 

15A% 

75.4% 

75.4% 

C-17 

24.6% 

24.6% 

24.6% 

24.6% 

24.6% 

Pax-  C-141 

52.2% 

34.2% 

34.2% 

34.2% 

34.2% 

C-5 

20.5% 

20.5% 

20.5% 

20.5% 

20.5% 

P-747 

27.3% 

45.3% 

45.3% 

45.3% 

45.3% 

*  Reptesents  the  number  of  iterations  performed  by  MINOS  5.2  to  find  an  optimal  solution  starting  from  the 
optimal  basis  of  the  previous  model. 


Since  die  airlift  scenario  was  designed  tc  make  each  of  the  resource  constraints  binding,  the 
otgective  function  “cost”  of  the  airlift  as  well  as  the  closure  (day  of  last  delivery)  is  expected  to 
increase  as  each  constraint  is  added.  It  is  interesting  to  note  that  the  number  of  sorties,  the 
percentage  of  SOTties  flown  by  each  aircraft  type,  and  the  percentage  of  cargo^ax  carried  by  each 
aircraft  type  does  not  change  after  the  first  constraint  (MOG)  is  added.  Further  investigation 
revealed  that  these  attributes  of  the  solution  are  relatively  insensitive  to  constraints  and  depend 
mostly  CHI  the  number  and  type  of  aircraft  eitqiloyed,  the  movement  requirements,  and  the  time 
windows  for  pickup  of  the  requirements  -  all  of  which  are  irqiut  parameters  to  the  model. 

Table  5  contains  the  usage  information  for  each  constrained  resource,  providing  further 
evidence  that  the  resource  constraint  equations  are  fimetioning  correctly.  However,  more  -etailed 
analysis  of  the  C-141  utilization  information  uncovered  a  flaw.  In  the  designed  scenario,  the 
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TABLES 


Constraint  Validation  -  Maximum  Resource  Levels 
(Otgective  Function  -  Minimize  Cost) 


Constrained  Resource 

Base 

MQG 

Thmpnt 

Avail 

UlE 

Maximum  MCXj  used  (percoit  of  cqiacity) 

KOOl 

591% 

68.2% 

50.8% 

52.2% 

56.0% 

iC002 

106% 

60.0% 

46.8% 

33.6% 

35.7% 

K003 

1,161% 

100% 

100% 

86.3% 

93.0% 

K004 

696% 

100% 

100% 

100% 

100% 

K005 

696% 

60% 

45.2% 

47.7% 

51.7% 

K006 

871%  - 

100% 

100% 

100% 

100% 

Maximum  Cargo  Throu|^put  (percent  of  capacity) 

K003 

2,167% 

211% 

100% 

100% 

100% 

K005 

867% 

127% 

60.0% 

60.0% 

60.0% 

Maximum  Passenger  Througlqiut  (percent  of  ctqiacity) 

K003 

548% 

78.0% 

41.6% 

48.4% 

50.8% 

K005 

1,370% 

195% 

100% 

100% 

100% 

Aircraft  Used  O^acent  of  availaUe) 

C-141 

904% 

485% 

268% 

100% 

100% 

C-5 

287% 

233% 

150% 

100% 

100% 

C-17 

314% 

298% 

158% 

100% 

100% 

P-747 

523% 

318% 

316% 

100% 

100% 

Surge  UlE  Rates  Achieved  (percent  of  maximum) 

C-141 

N/A 

N/A 

N/A 

298% 

100% 

C-5 

N/A 

N/A 

N/A 

151% 

100% 

C-17 

N/A 

N/A 

N/A 

171% 

100% 

P-747 

N/A 

N/A 

N/A 

138% 

100% 

C-141  aircraft  are  based  out  of  two  (fifferent  airfields  (KOOl  and  K002).  When  the  availability' 
and  UTE  levels  are  conq)uted  separately  for  each  group  of  C-141s,  as  in  Table  6,  two  problems 
become  evident  First  die  availaMity  constraint  is  enforced  across  aircraft  types,  allowing  the 
model  to  use  more  aircraft  than  are  available  from  each  operating  base.  This  occurred  at  both  of 
die  C-141  ';ases  at  some  time  during  the  planning  period  (though  not  at  the  same  time).  Similarly, 
die  UTE  constraints  are  enforced  over  an  aircraft  type,  allowing  the  model  to  over-utilize  the 
aircraft  from  an  advantageously  located  base  (K(X)2)  while  under-utilizing  the  aircraft  fixim  a  base 
fruther  from  the  on-load  airfields  (K(X)1)  to  maintain  the  required  overall  UTE  rates. 

Consequoitly,  die  ACEP  model  was  changed  to  enforce  both  availability  and  UTE  by  operating 
base  as  well  as  aircraft  type. 


TABLE 6 


Analysis  lof  Optimal  C-141  Utilization  by  Operating  Base 
(Objective  Function  -  Minimize  Cost) 


Aircraft/Qperating  Base  Availability  UXE 

C-141  (Overall)  100.0%  100.0% 

C-141  (KOOl)  150.0%  38.5% 

C-141  (K002) _ 174.0% _ 223.0% 


Alternative  (Xgectives.  The  final  step  in  the  constraint  validation  process  is  to  repeat  the 
process  of  examining  the  constraints  using  alternative  objective  functions.  Often  (me  of  the 
resource  constraints  can  be  used  as  an  objective  function,  with  the  goal  of  minimizing  the  use  of 
the  resource  sut^'ect  to  meeting  a  set  value  of  the  original  objective.  The  goal  in  switching  the 
constraints  and  objective  function  is  to  learn  mc^e  about  the  behavior  of  the  model  and  correct  any 
iiu^propriate  behavicff. 

For  this  step  of  the  validation  process  the  objective  function  chosen  is  to  maximize  the  flow 
of  cargo  and  passengers,  where  the  objective  function  value  reported  is  the  maximum  nuriiber  of 
pa.ssengers  and  tons  of  cargo  which  can  be  delivered  over  the  planning  period.  To  use  this 
objective  function,  it  is  assumed  that  an  infinite  amount  of  cargo  and  passengers  is  available  for 
pickup  at  each  on-load  airfield,  but  the  pickup  windows  are  not  changed.  Table  7  shows  the 
results  of  die  model  run  with  the  new  objective  function. 


TABLE 7 

Alternative  Objective  -  Effects  on  Solution 
(Objective  Function  -  Maximize  Flow) 


Solution  Characteristic.^ 

Base 

MQG 

UTE 

Thiuput 

#ofIterati(ms  * 

380 

1939 

882 

2648 

Objective  Function  Value 

64,908.00 

60,667.00 

52,023.18 

50,023.18 

Total#  of  Sorties 

498 

399 

402 

402 

Amount  Delivered  (by  class) 
Out  (tons) 

7,560.00 

7,376.65 

5,584.43 

5,425.02 

Blk  (tons) 

4,200.00 

349.18 

3,361.77 

3,521.19 

Passengers 

53,148 

52,941 

43,077 

43,077 

*  Represents  the  number  of  iterations  performed  by  MINOS  5.2  to  find  an  optimal  solution  starting  from  the 
optimal  basis  of  the  previous  model. 
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Since  the  resource  constraints  act  to  limit  the  flow  through  the  airlift  system,  the  objective 
fiinction  is  e;q)ected  to  decrease  as  each  constraint  is  added.  However,  it  is  also  evident  that  the 
moctel  tends  to  favor  the  delivery  of  passengers  over  cargo.  The  average  c£q}acity  of  the 
passenger-c^able  aircraft  (C-141  and  P-747  in  the  scenario)  is  about  250  passengers,  while  the 
average  edacity  of  the  caigo-cq)able  aircraft  (C-5,  C-17,  and  C-141)  is  about  40  tons.  Since  one 
passenger  and  one  ton  of  cargo  carry  equal  wei^  in  the  objective  function,  die  model  will 
naturally  attempt  to  schedule  as  many  of  the  higher  capacity  passenger  aircraft  as  possible. 
However,  Air  Force  planners  use  a  rule-of-diumb  that  one  ton  of  cargo  must  be  delivered  for  each 
passenger  [Litko,  1 592].  This  rule-of-thumb  has  proven  to  be  rou^y  accurate  in  past  airlift 
operadons  including  Desert  Shield.  This  ratio  is  true  for  the  operation  as  a  whole,  but  is  not 
necessarily  the  case  for  each  deploying  unit 

There  are  a  number  of  ways  to  indireedy  cause  die  model  to  deliver  roughly  equal  amounts 
of  cargo  and  passengers.  Hrst,  die  penalty  for  shortfall  in  the  cargo  categories  can  be  adjusted  to 
compensate  for  the  difference  in  the  carrying  c^acides  of  the  aircraft.  Second,  the  objeedve 
funedon  can  be  formulated  to  penalize  the  use  of  aircraft  to  carry  passengers.  However,  further 
experimentadon  with  these  soludons  showed  that  diey  are  only  effeedve  when  the  objeedve  is  to 
minimize  the  shortfall  and  the  airlift  system  does  not  have  the  edacity  to  delivo*  all  the  cargo  diat 
must  be  moved. 

The  best  way  to  direedy  influence  die  rado  of  cargq^assengeis  delivered  is  sinqily  to  add  a 
constraint  to  the  model  which  forces  die  shortfall  in  cargo  to  equal  the  shortfall  in  passengers 
within  some  specified  tlplerance.  In  the  case  where  the  objeedve  is  to  maximize  the  flow,  then  the 
constraint  will  force  thel  tons  of  cargo  delivered  to  rou^y  equal  the  number  of  passengers 
delivered.  A  single  new'constraint  (RATIO)  was  added  to  the  ACEP  model  to  force  the  tons  of 
cargo  (bulk  and  outsize)  delivered  to  be  within  10  percent  of  the  number  of  passengers.  This 
change  was  made  to  the  model  and  the  results  are  shown  in  Table  8.  The  effect  on  the  soludon  is 
dramadc,  but  results  in  a  rnore  realistic  delivery  of  cargo  and  passengers.  The  primary  “side 
effect”  of  the  new  constraint  in  the  test  scenario  is  that  the  C-141  aircraft  previously  used 
exclusively  for  carrying  passengers  are  now  used  only  for  carrying  bulk  cargo. 
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TABLES 


Alternative  Objective  -  Effects  on  Solution  #2 
(Otgective  Function  -  Maximize  Flow) 


Solution  Characteristic.s 

Basfi 

MOG 

IIIE 

Thruput 

Ratio 

#  of  Iterations  * 

380 

1939 

882 

26^ 

634 

Objective  Function  Value  64,908.00 

60,667.00 

52,023,18 

50,023.18 

22,014.08 

Total  d  of  Sorties 

495 

402 

402 

352 

Amount  Delivered  (by  class) 

Out  (tons) 

7460.00 

7,376.65 

5484.43 

5,425.02 

4556.09 

Blk  (tons) 

4,200.00 

349.18 

3,361.77 

3,521.19 

5871.63 

Passengers 

53,148 

52,941 

43,077 

43,077 

11,586 

Cargo  Mixture  (percent  of  total  delivered) 

Out-  C-5 

100% 

100% 

100% 

100% 

81.4% 

C-17 

18.6% 

Blk-  C-141 

62.2% 

C-5 

2% 

4.6% 

C-17 

100% 

98% 

100% 

95.4% 

37.8% 

Pax-  C-141 

55.0% 

55.3% 

58.1% 

58.1% 

C-5 

16.1% 

15.8% 

14.7% 

14.7% 

36.3% 

P-747 

28.8% 

29.0% 

27.2% 

27.2% 

63.7% 

Sortie  Mixture  (percent  of  total  by  aiicraft  type) 

C-141 

45.2% 

56.4% 

47.9% 

47.9% 

54.6% 

C-5 

25.3% 

30.8% 

23.2% 

23.2% 

174% 

C-17 

21,1% 

2.2% 

20.9% 

20.9% 

22.1% 

P-747 

8.4% 

104% 

8.0% 

8.0% 

5.7% 

Repicsents  the  number  of  iterationa  performed  by  MINOS  5.2  to  find  an  optimal  solution  starting  from  the 
optimal  basis  of  the  previous  model. 


Hnally,  the  effect  of  each  constraint  on  the  utilization  of  resources  is  given  in  Table  9.  When 
the  RATIO  constraint  is  added  to  the  model,  the  passenger-capable  aircraft  are  utilized  less  or  used 
to  deliver  bulk  or  outsize  cargo  and  the  passenger  throu^put  levels  decrease.  Thus,  the  model 
behavior  matches  what  is  eiqiected  when  the  model  is  forced  to  deliver  more  cargo. 

To  summarize,  the  primary  validation  task  in  the  model  implementation  stage  of  the  life  cycle 
is  to  verify  that  the  operational  model  correctly  inqilements  the  model  desiga  Specifically,  the 
goals  of  die  constraint  validation  process  are  to  verify  that  each  constraint  performs  it  primary  task 
of  constraining  the  use  or  consumption  of  the  resource;  to  ensure  that  no  unwanted  “side  effects” 
are  caused  by  the  constraint  equation;  and  provide  additional  insight  into  the  model  behavior. 

Three  techniques  were  used  to  conqilete  the  process  with  each  contributing  significantly  to 
die  validation  effort.  First,  a  scenario  was  develqied  to  “stress”  the  model  by  forcing  all 
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TABLE 9 


Alternative  Otjective  -Maxinrum  Resource  Levels 
(Ol^'ecdve  Fimcticxi  -  Maxiinize  How) 


Solution  Characteristics 

Base 

MOG 

IITR 

Thruput 

Ratio 

Maximum  MOG  used  percent  of  ctqiacity) 

KOOl 

120% 

68.7% 

69.4% 

65.4% 

62.7% 

K002 

54% 

33.88% 

47.4% 

53.4% 

51.2% 

K003 

289% 

100% 

100% 

100% 

100% 

K004 

199% 

100% 

100% 

100% 

100% 

KOOS 

173% 

60% 

60% 

60% 

55.1% 

K006 

434% 

100% 

100% 

100% 

100% 

Sustained  UTE  Rates  Achieved  (percent  of  maximum) 

C-141  (KOOl) 

105% 

105% 

100% 

100% 

100% 

C-141(K002) 

125% 

125% 

100% 

100% 

100% 

C-5 

135% 

132% 

100% 

100% 

66.4% 

C-17 

125% 

10.4% 

100% 

100% 

92.6% 

P-747 

131% 

131% 

100% 

100% 

62.9% 

Maximum  Cargo  Throughput  (percent  of  capacity) 

K003 

733% 

346% 

250% 

100% 

100% 

KOOS 

293% 

138% 

135% 

60.0% 

60.0% 

Maximum  Passenger  Throu^ut  ^lercent  of  c^adty) 

K003 

105% 

71.9% 

67.4% 

71.6% 

46.3% 

KOOS 

263% 

164% 

73.2% 

91.6% 

38.6% 

constraints  to  be  binding.  During  the  development  of  die  contrived  scenario,  the  penalty  for  using 
an  aircraft  in  the  otgective  function  was  modified  m  increase  with  time  to  minimize  closure  as  well 
as  shcfftfalL  In  addition,  it  was  discovered  that  marginal  cost  information  conqiuted  automatically 
oh  die  constrained  resources  could  be  aggregated  into  a  single  number  representing  the  relative 
importance  of  each  resource. 

Seccmd,  model  constraints  were  stripped  firom  the  basic  model  and  introduced  one  at  a  timft 
to  observe  their  individual  and  collective  effects  «i  the  solution  and  constrained  resources.  It 
was  discovered  diat  aircraft  availability  and  UTE  must  be  enforced  for  each  group  of  aircraft 
operating  firnn  the  same  airfield  as  well  as  across  aircraft  types. 

Hnally,  the  constraint  examination  process  was  repeated  with  an  alternative  objective 
function  of  maximizing  the  flow  of  cargo  and  passengers.  It  was  discovered  that  the  model  tends 
naturally  to  favor  die  delivery  of  passengers  over  cargo.  Consequently,  a  single  constraint  was 
added  to  force  the  mottel  to  deliver  rou^y  equal  amounts  of  cargo  and  passengers  within  a  given 
tolerance. 
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The  ACEP  model  is  now  fully  “operational”  The  last  step  in  the  proposed  model 
development  life  cycle  is  to  perform  one  or  more  post-development  validation  tests  to  determine 
how  the  model  performs  with  “live”  dat^ 


V.  R^wspective  Validatim  Test 

As  a  final  step  in  the  validation  process,  the  ACEP  model  is  used  to  “predict”  the  airlift 
cqtalnlity  of  the  Operation  Desert  Shield  airlift  system.  Since  die  lessons  of  the  Desert  Shield 
airlift  are  one  of  the  driving  faces  behind  the  develqiment  of  the  ACEP  model,  it  seems  fitting 
diat  die  validation  process  include  an  evaluatioi  of  die  model  performance  using  Desert  Shield 
data  In  addidon,diisaiiliftoperadon  represents  one  ofthe  largest  and  most  difficult  airlift 
operations  ever  undertaken,  providing  a  good  “stress”  test  fa  the  model. 

VaUdadonCMteda 

l^iecific  validadon  criteria  were  established  during  the  reconstrucdon  of  the  model 
lequitements  and  are  documented  in  the  ACEP  Model  Requirements  Specification  (^pendix  A). 
TItt  primary  otgecdve  of  the  model  is  to  “obtain  reasonable  estimates  of  the  number  and  type  of 
aiicraft  needed ...  and  identify  botdenecks  in  the  airlift  system”  (exceipt  from  ACEP  Model 
Requiiements  Specificadon).  Specifically,  four  aspects  of  the  model  were  chosen  as  the  most 
important  features  for  validadoi  purposes: 

(1)  Ease  of  use.  Information  that  is  required  for  input  to  the  model  must  be  easily 
obtainaUe  from  sources  already  available  in  the  planning  process  and  not  require 
extensive  transformations  pria  to  input 

(2)  Response  time.  The  model  must  provide  a  solution  to  a  problem  of  realistic  size  within 
areasonable  amount  of  time.  While  any  quantificatiaiofthis  criteria  is  purely  arbitrary, 
a  reasoiaUe  goal  may  be  to  provide  a  solution  to  a  30-day  planning  problem  within  30 
minutes  of  CPU  time  on  a  VAX  minicoitqru^. 

(3)  Accuracy.  The  model  must  be  able  to  determine  the  resources  required  to  perform  an 
airlift  flow  within  plus  a  minus  10  percent  of  the  actual  requirements.  This  criteria 
represents  a  compromise  by  the  model  sponsa  in  that  a  higher  degree  of  accuracy, 
while  certainly  desiraUe,  requires  an  unreasonable  amount  of  effort  in  both  obtaining 
input  data  with  a  carespoiding  degree  of  accuracy,  and  in  finding  an  optimal  solution. 
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(4)  Ou^uL  The  output  from  the  model  must  clearly  state  the  qptiinal  resource 

teqtdiements,  expected  shortfalls,  the  most  valuable  afrcraft  types,  and  idendiy  die 
msyor  airfield  botdenecks  in  the  systertL 

The  first  two  criteria  -  ease  of  use  and  response  time  -  become  very  in^ortant  when  the  model  is 
used  during  execution  planning,  which  is  the  more  demanding  use  of  the  model  Note  that  the 
validaticm  criteria  are  established  during  the  requirements  analysis  stage  of  die  life  cycle  and  are 
chosen  by  the  model  user  -  not  the  model  developer  -  to  represent  the  most  important  goals  of  the 
model 

Scaaiio 

At  0100  (Kuwait  dme)  on  2  August  1990,  three  Iraqi  Republican  Guard  divisions  began  a 
ground  assault  into  the  neighboring  country  of  Kuwait  At  the  same  time,  special  forces  from 
Iraq  attacked  Kuwait  City  and  the  Amir’s  palace.  By  1900  the  same  day,  the  country  was  all  but 
lost  and  fraqi  forces  began  massing  in  an  tqiparent  threat  to  advance  into  Saudi  Arabia,  l^esident 
Bush  ordered  the  start  of  operation  Desert  Shield  [Conduct  of  the  Persian  Gulf  War,  1992: 1]. 

One  of  the  primary  military  objectives  of  Desert  Shield  was  to  develqi  a  defensive  c^ability 
in  the  Persian  Gulf  region  to  deter  Iraq  from  further  attacks  [Conduct  of  the  Persian  Gulf  War, 
1992: 40].  The  Military  Airlift  Command  (MAC  -  the  predecessor  to  AMC)  was  feced  with  the 


Figure  12.  Overview  of  Desert  Shield  Airlift  System 
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problem  of  moving  an  unprecedented  military  force  halfway  around  the  world  in  as  short  a  time 
as  possiUe.  Figure  12  shows  an  overview  of  the  airlift  system  on  a  regional  mq).  Virtually  half 
the  fleet  of  strategic  transport  aircraft  owned  by  MAC  as  well  as  civil  reserve  aircraft  were  used  in 
flie  airlift  After  six  months  of  almost  round-the-clock  airlift,  more  than  500,000  troops  and 
544,000  tons  of  cargo  had  been  moved  [Conduct  of  the  Persian  Gulf  War,  1992:  E-9]. 


The  Desert  Shield  MaM 

The  operational  ACEP  model  is  used  to  predict  30  days  of  Desert  Shield  operation.  Since 
(fetailed  records  on  the  first  30  days  are  difficult  to  find,  the  input  data  represents  the  daily  or 
monthly  (as  rqipropriate)  average  over  the  first  180  days  of  the  operation,  and  only  sustained 
UTE  rates  are  enforced.  Each  time  unit  in  the  model  represents  one  day  in  die  airlift 

AirSeld  Resources,  The  ACEP  model  of  the  Desert  Shield  deployment  uses  15  primary 
airfields.  The  on-load  airfields  are  located  in  the  continental  United  States  and  Europe.  The  off¬ 
load  airfields  are  aU  located  in  Saudi  Arabia  Table  10  lists  the  International  Civil  Aviatiem 
Organization  (ICAO)  designators,  locations,  capacities,  and  primary  uses  of  the  15  airfields. 


TABLE  10 


Desert  Shield  Airfield  Resources 
(Source:  AMC/XPYR) 


ICAO 

De.signatnr  Location 

Primary  tJ.se 

Maximum  on 
the  Ground 

Throughput  Capacity 
Caign  Passengers 

KDOV 

Dovct  AFB,  DL 

C-5  Base/On-load  Unlimited 

5,000 

15,000 

KCEF 

Westover,  MA 

Enroute 

Unlimited 

N/A 

N/A 

KCHS 

Charleston  AFB,  SC 

C-141Base 

Unlimited 

N/A 

N/A 

KWRI 

McGuire  AFB,  W 

Enroute 

Unlimited 

N/A 

N/A 

KFOE 

Fort  Riley,  KS 

On-load 

Unlimited 

5,000 

15,000 

KNON 

Notional  U.S. 

On-load 

Unlimited 

5,000 

15,000 

EXXX 

Notional  Europe 

Enroute 

500 

N/A 

N/A 

EDAF 

Frankfurt,  Germany 

On-load 

144 

5,000 

15,000 

EDAR 

Ramstein,  AB 

On-load 

42 

5,000 

15,000 

LETO 

Torrejon,  AB 

Enroute 

160 

N/A 

N/A 

LE2A 

Zaragoza  AB 

Enroute 

24 

N/A 

N/A 

OEDR 

Dhahran,  SA 

Off-load 

40 

2,500 

11,000 

OEIB 

Jubayl,  SA 

Off-load 

15 

1,500 

7,300 

OEDF 

King  Fahd,  SA 

Off-load 

40 

1,400 

4,100 

OEKK 

KingKhalid,SA 

Off-load 

31 

450 

1,600 

\  ' 
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The  EXXX  and  KNON  airfields  are  notional  for  a  number  of  European  and  U.S.  airfields 
(respectively)  with  significant  involvement  in  the  airlift.  The  MOG  information  represents  an 
aggregation  of  parking  and  working  MOG  at  each  airfield. 

Primary  Routes.  The  32  primary  routes  used  by  the  airlift  aircraft  included  as  many  as  six 
stops  to  cover  the  7,(XX)  to  10,000  miles  between  tire  U.S.  and  the  Mideast  and  return.  In  the 
GAMS  model,  a  route  consists  of  a  sequence  of  airfields  with  the  first  and  last  airfield  being  the 
operating  base  of  the  aircraft.  The  second  stop  is  normally  the  on-load  airfield.  A  typical  ACEP 
representation  of  a  route  is  shown  in  Table  1 1.  The  flight  time  between  airfield  pairs  must  be 
included  to  compute  UTE  rates.  For  the  route  in  Table  1 1  (route  ROOl  in  the  modelX  tire  round 
trip  mission  requires  approximately  13.7  hours  of  flight  time  during  the  first  24  hours,  17.2 
hours  during  the  second  24  hoirrs,  and  6.6  hours  on  the  third  day.  Similarly,  the  delay  at  each 
stq)  must  be  known  to  compute  the  time  period  after  the  start  of  the  route  when  each  airfield  will 
be  visited.  The  ground  time  at  each  stop  is  a  function  of  the  aircraft  type  and  the  purpose  of  the 
stop.  In  the  case  where  more  than  one  type  of  aircraft  can  use  the  same  route,  the  fli^  times  and 
ground  times  are  averaged  rather  than  including  separate  routes  for  each  aircraft  type.  This  is 
dote  to  help  reduce  the  size  of  the  model  so  that  the  required  response  time  may  be  met 
(^rpendix  D  contains  a  table  of  fli^t  times  between  airfields  and  ground  times). 


TABLE  11 

Typical  E)esert  Shield  Route 
(Route  #1  -  C-5  only) 


Start 

End  or 

Fly 

Ground 

Cumulative 

Day  of 

Route  Leg 

Airfield 

Activity 

Time 

lime 

Time 

Visit 

1 

KDOV 

KFOE 

3.1 

3.10 

[0] 

KFOE 

On-load 

4.25 

7.35 

2 

KFOE 

KCEF 

3.1 

10.45 

KCEF 

Enroute 

3.25 

13.70 

3 

KCEF 

LETO 

7.5 

21.20 

LETO 

Enroute 

3.25 

24.45 

[1] 

4 

LETO 

OEDR 

7.0 

31.45 

OEDR 

Off-load 

3.25 

34.70 

5 

OEDR 

LETO 

8.2 

42.90 

LETO 

Enroute 

3.25 

46.15 

6 

LETO 

KDOV 

8.6 

54.75 

(21 
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Note  that  each  airfield  visited  on  a  route  is  affected  by  die  visit  for  an  entire  unit  of  time.  For 
exanqile,  in  the  Desert  Shield  model  (one  time  unit  =  one  day),  the  MOG  and  throughput  (when 
qiplicable)  avail^le  at  each  airfield  visited  on  each  day  of  the  mission  is  reduced  for  the  entire 
day.  Using  smaller  units  oftime  reduces  the  effect  but  increases  the  size  of  the  model  This 
demonstrates  anotho'  of  the  trade-offs  that  must  be  made  between  modeling  accuracy  and  model 
size. 

Ahcraft  Resources.  The  C-S  Galaxy  and  C-141  Stafiifier  represented  the  primary  strategic 
airlift  cqiability  of  the  U.S.  Air  Force  during  the  conflict  hi  addition,  aircraft  from  the  civil 
reserve  air  fleet  (CRAF)  were  activated  for  duty  throughout  the  operation.  Table  12  lists  the 
primary  strategic  airlift  availaUe  and  also  lists  die  preferred  cargo  type  and  maximum  designed 
capacity,  and  non-preferred  cargo  type  and  ct^acity  where  appropriate. 


TABLE  12 

Desm  Shield  Aircraft  Resources 
(Source:  AMC/Command  Analysis  Group) 


Aircraft 

Type 

Home  Airfields 

Ereferred 

CarEo  Tvne  Canacitv 

Non=preferred 

Cargo  Tvne  Canacitv 

C-5  ■ 

KDOV,KNON, 

Outsize 

68.9  tons 

Passengers 

75 

EDAF 

Bulk 

68.9  tons 

Passengers 

75 

C-141 

KCHS,EDAR 

Bulk 

27  J  tons 

Passengers 

10 

Passengers 

136 

CRAF  747 

KDOV,KNON 

Bulk 

87.3  tons 

Passengers 

365 

CRAF  707 

KDOV,KNON 

Bulk 

41.1  tons 

CRAF  DC-10 

EXXX 

Passengers 

235 

Note  that  while  the  home  base  of  the  aircraft  is  known,  the  Desert  Shield  schedulers  often 
repositioned  aircraft  to  take  advantage  of  available  crews.  Consequently,  the  aircraft  availability 
and  UT  E  constraints  are  enforced  only  over  aircraft  types,  and  not  by  operating  base.  Table  13 
lists  the  total  number  of  each  type  of  aircraft  available  for  Desert  Shield  missions  during  the  first 
six  months,  the  MOG  used  by  each  aircraft  type,  and  the  objective  sustained  UTE  rates. 

Movement  Recpiirements.  The  movement  requirements  are  divided  into  three  classes: 
outsize  cargo,  bulk  cargo,  and  passengers.  Oversize  cargo  is  included  with  the  bulk  cargo 
because  tiie  amount  of  oversize  cargo  is  not  normally  known  during  deliberate  planning.  The 
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TABLE  13 

Desert  Shield  Aircraft  -  Number,  MOG  and  UTE 
(Source:  AMC/Command  Analysis  Group) 


Aircraft 

Number 

MOG 

Objective 

Jype- 

Available 

Used 

UTE  Rate 

C-5 

112 

2.0 

9.0 

C-141 

230 

LO 

10.0 

CRAF747. 

20 

2.1 

10.0 

CRAF707 

15 

1.0 

10.0 

CRAF  DC-10 

5 

2.0 

10.0 

units  from  which  the  requirements  originate  are  notional.  Each  combination  of  cm-load  airfield 
and  off-load  airfield  is  represented  by  a  unit  The  data  was  obtained  by  working  backward  from 
a  list  of  the  actual  airlift  requirements  for  a  typical  30  day  period  TaNe  14  shows  the  notional 
units  used  to  represent  the  valid  combinations.  Hie  outsize  and  bulk  cargo  requirements  are 
eiqiressed  in  tons.  Note  that  die  average  monthly  capability  of  the  Desert  Shield  airlift  was 
61,203  tons  of  cargo  and  71,167  passengers.  Thus  the  total  amount  of  airiift  requirements  in 
each  category  exceeds  the  c^ability  of  the  system  by  some  25,000  tons  of  cargo  and  7600 
passengers,  as  was  typical  throughout  most  of  the  first  180  days. 


TABLE  14 

Notional  Desert  Shield  Military  Units  and  Requirements 
(Source:  AMCTXPYR) 


Unit 

On-Load 

Off-Load 

Number 

Airfield 

Airfield 

Outsize 

Bulk 

Eassengers 

UOl 

KFOE 

OEDR 

5,670 

6,500 

6,850 

U02 

KFOE 

OEIB 

3,276 

2,800 

3,536 

U03 

KFOE 

OEDF 

2,646 

25,930 

U04 

KFOE 

OEKK 

3,375 

U05 

KDOV 

OEDR 

36,378 

25,160 

U06 

KDOV 

OEJB 

4,582 

2,176 

U07 

KDOV 

OEKK 

9,704 

5,168 

U08 

EDAF 

OEDR 

1,764 

2,079 

7,178 

U09 

EDAF 

OEIB 

882 

252 

1,224 

UlO 

EDAF 

OEKK 

882 

567 

1,564 

Ull 

EDAR 

OEDR 

3,393 

U12 

EDAR 

OEJB 

1,034 

U13 

EDAR 

OEKK 

1,307 

TOTALS 

15,120 

71,971 

78,786 
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Analysis  of  Model  Perfmnance 

To  begin  the  task  of  evaluating  the  perfomiance  of  the  Desert  Shield  model  against  “live” 
data,  the  model  was  solved  using  the  primary  otgeciive  funcdcm  of  minimizing  shortfall.  The 
model’s  performance  in  solving  dds  problem  was  evaluated  against  the  established  validation 
criteria  in  four  areas  -  ease  of  use,  response  dme,  accuracy,  and  output 

Ease  of  Use.  Minmadon  that  is  required  for  iiq)ut  to  die  model  must  be  easily  obtainable 
from  sources  already  available  in  the  planning  process  and  not  require  extensive  transformadons 
priOT  to  ii^ut  For  the  most  part,  ail  of  die  infomadon  required  to  generate  a  soludon  to  a  given 
airlift  scenario  is  easily  available  to  the  airlift  planners.  The  model  is  flexible  in  that  it  can 
accommodate  almost  any  level  of  detail  In  general  more  detailed  informad^  on  the  movement 
requirements,  airfield  siqiport  cqiacides,  and  pickiqi  time  windows  should  result  in  a  more 

accurate  soluticm,  but  even  very  rough  and  inconqilete  infmmadon  can  be  used  to  build  a  model 

i 

diat  provides  some  useful  informadon.  Some  parameter  data  for  the  model  rnay  be  difficult  to 
develop,  however.  For  exanqile,  the  parking  MOG  fix'  each  airfield  is  relatively  constant  and  can 
be  found  in  a  directory  of  airfields,  but  working  MOG  is  dependent  iqion  many  factors  including 
any  simultaneous  supptxt  the  airfield  must  provide  to  aircraft  not  involved  iii  the  airlift  under 
study. 

To  fully  utilize  the  power  of  the  model  requires  a  significant  amount 
Each  route  must  be  analyzed  in  a  manner  similar  to  Table  11,  where  the  fli^t  time  between 
airfields  and  ground  times  during  stops  are  estimated,  hi  addition,  when  the  flight  times  and 
ground  times  differ  significantly  by  aircraft  type,  a  separate  route  should  be  included  for  each  type 
of  aircraft  that  can  fly  the  route.  This  can  greatly  increase  the  number  of  routes  required.  Overall, 
however,  the  amount  of  data  preparation  required  to  develop  a  solution  to  an  aiiiift  of  the 
magnitude  of  Desert  Shield  was  not  unreasonable.  The  real  judges  of  how  easy  the  model  is  to 
use  are  the  aiiiift  planners  at  AMC. 

Respatse  Time.  The  model  must  provide  a  solution  to  a  problem  of  realistic  size  within  a 
reasonable  amount  of  time,  with  a  plausible  goal  being  to  provide  a  solution  to  a  30  day  planning 
proUem  within  30  minutes  of  clock  time  (xi  a  minicomputer.  The  GAMS  code  executed  to  obtain 
a  solution  to  tfie  Desert  Shield  scenario  contained  two  models  -  the  first  to  minimize  shortfall,  and 
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the  second  to  maximize  flow  using  the  same  data.  On  average,  an  optimal  solution  was  found  and 
reported  by  GAMS  in  j^jproximately  25  CPU  minutes  running  on  a  VAX  1 1/785  minicomputer. 

The  primary  factors  in  the  solution  ttme  of  any  linear  program  are  the  size  of  the  model  (in 
terms  of  the  number  of  variables  and  the  number  of  constraints),  and  the  density  of  the  constraint 
matrix.  TaUe  15  shows  die  model  size  and  density  of  the  two  GAMS  models.  The  number  of 
constraints  in  die  model  is  primarily  a  function  of  the  number  of  movement  requirements,  routes, 
aiicraft  types,  and  time  periods.  Of  these,  the  airlift  planner  really  only  controls  die  tune  periods 
used  by  deciding  on  the  unit  of  time.'  A  smaller  unit  of  time  will  result  in  more  constraints  and  a 
larger  model.  The  number  of  variables  is  also  a  functiai  of  the  movement  requirements,  routes, 
aiicraft  types,  and  time  periods,  as  well  as  the  cargo  classes.  However,  the  number  of  variables 
vtdiich  are  candidates  to  become  tesic  (nonzero)  in  the  solution  is  controlled  by  the  pickup 
window  of  the  requirements  (DELTA).  Thus,  tighter  and  more  detailed  pickup  windows  will  also 

constrain  the  solution,  resulting  in  a  reduced  solution  time. 

« 

TABLE  15 

Desert  Shield  -  Model  Size  and  Density 

Number  of  Nuraber  of  Constraint 
Model  Objective  Variables  ron.stTaint.s  Matrix  Density 
Minimize  ShortfaU  3028  2020  0.00579 

_ Maximize  Row _ 3001 _ 1993 _ 0.00565 _ 

Accuracy.  The  accuracy  of  an  airlift  model  can  be  difEcult  to  determine  even  when 
conq)ared  against  historical  data  fOT  two  reasons.  First,  the  model  provides  an  uptimal  solution 
to  a  given  problem,  whereas  the  historical  solution  is  proven  only  to  be  feasible.  Thus,  even  if 
the  model  is  a  perfect  representation  of  the  real  problem,  the  model  solution  may  be  very  different 
frmn  the  historical  solutioa  Second,  there  is  likely  to  be  a  large  number  of  feasible  model 
solutions  with  objective  function  values  equal  to  (alternative  optimal  solutions)  or  nearly  equal  to 
the  one  q)timal  solution  reported.  Any  detailed  analysis  of  the  solution  must  consider  these  facts. 

The  primary  solution  characteristics  of  interest  are  the  total  amount  of  cargo  and  passengers 
delivered  (the  airlift  ctqjabUity  of  the  system),  the  size  and  composition  of  the  fleet  of  transport 
aircraft  used  and  (to  a  lesser  extent)  the  utilization  of  the  aircraft  and,  finally,  the  airfields  which 
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are  bottlenecks  in  the  system.  Where  the  characteristic  can  be  quantified,  the  goal  of  the  model 
^onsor  is  to  predict  die  characteristic  to  within  10  percent  of  the  “real”  value.  The  first  step  is  to 
solve  die  model  and  compare  die  model  solution  to  the  Desert  Shield  operation.  The  model 
sdution  to  the  Desert  Shield  airlift  proUem  is  compared  to  factual  data  in  Table  16. 


TABLE  16 

ACEP  Desert  Shield  Solution  Summary  #1 
(Using  Maximum  Designed  Aircraft  Cqiacities) 


ACEP  Desert 

Solution  Characteristic  Minimize  Cost  Shield 
Objective  Function  V'alue  143,340,89  337,030  * 

Total  Number  of  Missie  s  1200  1960 

*Estiiiuited  by  plugging  the  average  D.S.  snortfall  and  number  of  missions  into  the  Min  Cost  Obj  Function. 


Ingure  13  shows  graphically  a  comparison  of  the  amount  of  cargo  and  passengers  delivered. 
The  model  has  found  a  solution  which  delivers  10.7%  more  passengers,  19.1%  more  cargo,  and 


80,000 


0 


ACEP  Objective: 
Aircraft  Payload: 


Passengers  Cargo 


Minimize  Shortfall 
Maximum  Designed  Payload 


£>esert  Shield 


i - 1  ACEP  Model 


Passengers  Cargo 

Desert  Shield*  71,167  61,203 

ACEP  Model  78,786  72,877 

*  30  day  Average  over  the  fint  iSO  days 


Figure  13.  Comparison  of  Amount  Delivered  (Max  Aircraft  Payload) 


uses  38.7%  fewer  missions  than  the  actual  operation.  Also,  the  way  in  which  ACEP  uses  the 
aircraft  to  deliver  the  cargo  is  very  different  from  tiie  way  it  was  actually  accomplished.  Figure 
14  shows  a  comparison  of  each  aircraft’s  share  of  the  total  number  of  missions  flown  over  the  six 
month  period.  The  information  is  aggregated  into  four  aircraft  categories  -  C-5,  C-141 ,  Wide 
Body  (WB)  which  represents  the  CRAF  747  and  DC-10  aircraft,  and  Narrow  Body  (NB)  which 
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represents  the  CRAF  707  aircraft.  It  is  evident  from  Rgure  14  that  the  model  tends  to  favor  the 
C-5  aircraft  and  avoids  use  of  the  lower-capacity  C-141  and  narrow  body  707  airaaft.  Similarly, 
Rgures  15  and  16  show  the  share  of  passengers  and  cargo,  respectively,  carried  by  each  aircraft 
type  in  both  the  Desert  Shield  airlift  and  the  model  solution.  Again  the  model  solution  relies 
heavily  (Hi  the  C-S,  and  uses  none  of  the  available  707  aircraft.  Rnally,  Rgure  17  presents  a 
comparison  of  aircraft  utilization.  Again,  it  is  clear  that  the  model  favors  the  hi^-capacity  C-5 
and  wide  body  CRAF  aircraft  over  the  C-141  and  narrow  body  CRAF  aircraft. 
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Minimize  Shortfall 
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C-141 

6.1 
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WB 
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0.0 

Figure  17.  Summary  of  Aircraft  Utilization  (Max  Aircraft  Payload) 


The  results  of  this  initial  model  beg  the  question:  Why  did  the  airF  ft  planners  in  Desen 
Shield  schedule  nearly  2000  missions  each  month  using  an  average  of  184  aircraft  each  day  when 
a  substantially  greater  amount  of  cargo  and  passengers  can  be  delivered  with  40%  fewer  missions 
and  50  fewer  aircraft?  Obviously  some  important  considerations  in  the  scheduling  process  that 
determine  the  size  and  composition  of  the  fleet  necessary  to  perform  a  real  airlift  like  Desen  Shield 
are  not  accounted  for  in  the  model. 

At  least  pan  of  the  answer  lies  in  the  apparent  inability  of  the  load  planners  to  fully  utilize  the 
pt^load  capabilities  of  the  aircraft.  Table  17  compares  the  maximum  designed  payload  of  the 
strategic  airlift  force  with  the  average  payload  achieved  in  I>esert  Shield.  A  new  ACEP  model 
was  developed  and  the  results  of  using  the  actual  achieved  payload  information  in  the  model 
shows  that  the  model  does  a  remarkable  job  of  predicting  the  flow  capability  of  the  airlift  system, 
but  achieves  the  flow  with  a  significantly  different  fleet  of  aircraft. 
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TABLE  17 


Desert  Shield  Achieved  Payloads 
(Source:  AMC/Command  Analysis  Groiq?) 


Aircraft 

Type 

Cargo 

Class 

Maximum 
Designed  Payload 

Desert  Shield 
Achieved  Payload 

C-5* 

Outsize/Bulk 

^.9  tons 

62  tons 

C-141  ** 

Bulk 

27.5  tons 

19  tons 

Passengers 

136 

112 

WB747 

Bulk 

87.3  tons 

75  tons 

Passengers 

365 

286 

NB707 

Bulk 

41.1  tons 

24  tons 

WB  DC-10 

Passengers 

235 

180 

*  24  of  the  75  passenger  seats  on  the  C-S  (non-preferred  cargo)  were  filled  on  average. 
C-141  aircraft  carrying  bulk  cargo  also  carried  10  passengers  on  average. 


Table  18  compares  the  ACEP  solutions  obtained  using  the  maximum  designed  payloads 
from  Table  12,  the  Desert  Shield  achieved  payloads  from  Table  17,  and  the  actual  Desert  Shield 
solution  which  is  based  on  historical  records  from  the  airlift. 


TABLE  18 

ACEP  Desert  Shield  Solution  Summary  #2 


- Aircraft  Payload - 

Desert 

Solution  Characteristic 

Maximum 

Achieved 

Shield 

Objective  Function  Value 

143,340.89 

318,482.75 

337,030 

Passengers  Delivered 

78,786 

72,141 

71,167 

Tots  of  Cargo  Delivered 

72,877 

62,041 

61,203 

Total  NumbCT  of  Missions 

1200 

1530 

1960 

Avaage  Number  of  Aircraft 

133 

169 

184 

The  delivery  c^ability  of  the  new  model  solution  using  the  achieved  aircraft  payloads  is 
much  closer  to  Desert  Shield  figures.  The  model  is  able  to  predict  the  number  of  passengers 
delivered  to  within  974  passengers  (1.7%)  and  the  amount  of  cargo  delivered  to  within  838  tons 
(1.4%)  of  the  actual  30-day  average.  The  model’s  prediction  of  delivery  capability  is  now  well 
witiiin  the  specified  accuracy  tolerance  of  10  percent,  but  to  achieve  this  accuracy  the  model  must 
be  developed  using  an  accurate  estimate  of  the  achievable  cargo  load  for  each  aircraft  type.  In 
ttldition,  the  fleet  of  aircraft  used  in  the  new  model  solution  is  still  largely  comprised  of  C-S  and 
CRAF  wide  body  aircraft.  Since  the  larger  aircraft  carry  greater  payloads  per  mission,  fewer 
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Figure  18.  Summary  of  Aircraft  Utilization  (Achieved  Payload) 

missions  are  required.  This  is  die  major  reason  why  23%  fewer  missions  are  needed  in  the 
model  solution.  Figure  18  summarizes  the  utilization  of  aircraft  in  the  new  model  soludon. 

There  are  a  number  of  factors  that  could  explain  the  remaining  differences  in  the  solutions  of 
the  model  and  the  Desert  Shield  planners.  Some  of  the  possible  factors  are  identified  in  the  final 
report  to  Congress  on  the  Persian  Gulf  war.  These  are: 

•  Nearly  60  percent  ofthe  cargo  delivered  by  airiift  was  oversize  and  could  not  be  carried 
by  commercial  (CRAF)  cargo  aircraft  [Conduct  of  die  Persian  Gulf  War,  1992:  F-38]. 

•  The  U.S.  provided  substantial  airlift  resources,  primarily  C-5s,  to  other  Coalition 
members,  limiting  the  number  of  C-5s  available  for  carrying  U.S.  cargo  and  passengers 
[Conduct  of  the  Persian  Gulf  War,  1992:  E-9]. 

- Other  possible  factors  which  might  increase  the  utilization  ofC-141  aircraft  are  identified  by 

Major  Killingsworth  in  “Estimating  and  Supporting  Future  Airlift  Forces”  [Killingsworth,  1991]. 
He  describes  a  number  of  (Relational  constraints  that  limited  the  deployment  even  before  the 
number  of  aircraft  available  became  important  These  are: 

•  The  inalality  of  the  airlift  customers  to  keep  up  with  the  airlift.  In  the  early  stages,  aircraft 
and  aircrew  were  positioned  at  the  on-load  airfields  faster  than  the  users  could  generate 
loads.  The  result  was  “backlogs  of  MAC  aircraft  waiting  to  be  loaded ...  on  ramps  all 
over  the  country”  [Killingsworth,  1991: 20].  ITiis  rush  to  load  aircraft  and  get  them  in 
the  air  would  favor  the  lower-capacity  C-141  aircraft. 
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•  Lack  of  an  in-theatCT  crew  stage  base  and  “bum-out”  of  the  aircrew.  “Eventually,  the 
udlizaiitm  rates  started  taking  a  toll,  as  aircrews  pushed  their  30-  and  90-day  flying 
h(xir  limitations  -  a  situation  that  was  exacerbated  by  the  lack  of  an  in-theat^  stage  crew 
pperatitHi  (a  base  in  Saudia  Arabia  where  flesh  crews  would  be  available  for  flying  the 
return  leg  of  the  mission)”  [Killingswoth,  1991: 20].  While  there  is  no  direct  evidence 
that  aircrew  factors  limited  the  use  of  the  C-5,  it  is  likely  drat  some  effort  was  made  to 
^ad  Are  flying  hours  evenly  amtmg  the  available  crews  to  avoid  “bum-out”.  Again, 
this  wtnild  tend  to  favw  the  more  numerous  C-141  aircraft  over  the  C-5. 

Using  this  new  information,  a  new  ACEP  model  was  developed  and  solved  which  limited 
the  utilization  of  the  C-5  aircraft  to  the  average  6-month  UTE  rate  achieved  in  Desert  Shield.  The 
results  are  presented  in  Table  19. 


TABLE  19 

ACEP  Desert  Shield  Solution  Summary  #3 


—  Aircraft  Payload  — 

Limited 

Desert 

Solution  Characteristic 

Maximum 

Achieved 

C^.UTE 

Shield 

Objective  Function  Value 

143,340.89 

318,482.75 

325,852.84 

337,030 

Passengers  Delivered 

78,786 

72,141 

71,761 

71,167 

Tons  of  Cargo  Delivered 

72,877 

62,041 

61,715 

61,203 

Total  Number  of  Missions 

1200 

1530 

1840 

1960 

Average  Number  of  Aircraft 

133 

169 

189 

184 

The  model  solution  is  now  roug^y  equal  to  the  solution  used  in  Desert  Shield.  Hgures  19 
and  20  show  that  the  aircraft  utilization  and  the  contribution  of  each  type  of  aircraft  to  the  airlift 
are  q)proximately  equal.  However,  to  achieve  tiiis  solution  the  C-5  aircraft  UTE  rate  must  be 
ccxistrained  below  the  maximum  sustained  rate. 

The  new  soluticm  provides  a  valuable  discovery  -  the  Desert  Shield  solution  is  a  feasible 
solution  in  the  model!  Had  it  not  been  so,  the  validity  of  the  model  would  be  much  harder  to 
justify.  However,  to  achieve  the  Desert  Shield  solutitm  using  the  model,  factors  such  as  loading 
delays  and  aircrew  “bum-out”  have  been  incOTporated  indirectly  adjusting  the  C-5  UTE  rate. 
It  is  unclear  to  what  extent  airlift  planners  would  have  advance  knowledge  of  such  factors. 
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Figure  19.  Summary  of  Aircraft  Utilization  (C-5  UTE  =  5.6) 


ACEP  Objective:  Minimize  ShortM 

Aircraft  Payload:  Desert  Shield  Average 


Desert  Shield  (6  month  average)  ACEP  Model 


Figure  20.  Percent  of  Total  Missions  by  Aircraft  Type  (C-5  UTE  =  5.6) 

Hie  model  was  more  consistent  in  identifying  the  airfield  bottler>ecks  in  the  system.  Each 
model  solutim  was  approximately  the  same  in  this  regard.  The  bottlenecks  identified  by  the 
model  in  each  of  die  throu^ut  constraint  categories  -  cargo  and  passenger  throughput  -  are 
presented  in  Hgures  21  and  22.  Note  that  only  King  Khalid  airfield  (OEKK)  reached  a  limit,  but 
the  marginal  value  of  the  througiqiut  constraint  at  this  airfield  indicates  that  a  significant 
itrqnrovement  in  objective  function  cmdd  be  experienced  by  increasing  the  cargo  handling 
ct^ability  (MHE)  of  the  airfield.  The  final  report  to  Congress  on  Desert  Shield  states  that 
shortages  in  some  types  of  MHE  at  the  off-load  airfields  (specific  airfields  not  identified)  resulted 
in  extended  ground  times  early  in  the  airlift  [Conduct  of  the  Persian  Gulf  War,  1992:  F-25]. 
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ACEP  Objective; 
Aircraft  Payload: 


Miniinize  Shortfall 
Desert  Shield  Average 


Cargo  Throughput  Used  (Percent  of  Maximum) 
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Marginal 

Value 

503.1 
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Figure  21.  Summary  of  Airfield  Cargo  Throughput 


ACEP  Objective:  Minimize  Shortfall 

Aircraft  Payload:  Desert  Shield  Average 

Passenger  Throuj^put  Used  (Percent  of  Maximum) 


Marginal 

Value 


KDOV  EDAF  OEDR  OEKK 

KPOE  EDAR  OEJB  OBDP 


Figure  22.  Summary  of  Airfield  Passenger  Throughput 


ACEP  Objective: 
Aircraft  Payload: 


Minimize  Shortfall 
Desert  Shield  Average 


Airfield  MOG  Used  (Percent  of  Maximum) 


EDAR 

Marginal 

Vahie 

0.1 

LETO 

0.2 

LEZA 

0.1 

OEDR 

15,970.9 

OEJB 

3,499.2 

OEKK 

0.1 

OEDF 

44.1 

KDOV  KCHS  KPOB  EDAF  EXXX  LEZA  OEJB  OEDF 
KCEF  KWRI  KNON  EDAR  LETTO  OEDR  OEKK 


Figure  23.  Summary  of  Airfield  MOG 

Many  of  the  enroute  airfields  and  all  of  the  off-load  airfields  in  Saudi  Arabia  reached  their 
MOG  limits  at  some  time  during  die  planning  period  of  the  model.  Figure  23  provides  a  summary 
of  the  utilization  of  MOG  (parking  and  working  MOG)  at  each  airfield  and  the  aggregated 
marginal  value  for  each  airfield  that  reached  100  percent  of  MOG  capacity.  The  airfields  ar  ‘:  listed 
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with  the  on-load  airfields  on  the  left,  the  enroute  airfields  in  the  middle,  and  the  off-load  airfields 
(XI  die  right  The  graph  makes  it  very  obvious  that  the  enroute  and  off-load  airfields  represent  the 
primary  bottlenecks  in  the  airlift  system.  The  marginal  values  indicate  that  the  most  critical  of  the 
MOG-constrained  airfields  are  the  off-load  fields  in  Saudi  AraUa.  In  fact  the  marginal  value  for 
ENiahran  (OEDR)  indicates  that  the  objective  function  can  be  improved  by  as  much  as  15,970 
(5%)  simply  by  increasing  the  MOG  at  this  airfield  by  one  unit  across  die  30  days  (again  this 
assumes  no  change  in  the  optimal  basis  -  the  actual  improvement  is  10,664.0).  The  model’s 
identification  of  these  airfields  as  the  most  critical  botdenecks  in  the  airlift  matches  well  the 
situation  found  in  Desert  Shield  [Conduct  of  the  Persian  Gulf  War,  1992;  E-8]. 

To  summarize  the  findings  on  the  accuracy  of  the  ACEP  mo(tel,  the  model  seems  to  perform 
well  with  the  limited  information  diat  would  be  available  to  airiift  planners  during  deliberate 
planning  only  in  predicting  the  flow  ctqiability  and  the  airfield  botdenecks.  Even  in  the  deliberate 
planning  mode,  an  estimate  of  die  operational  payload  capability  of  the  aircraft  must  be  known. 
When  additional  information  is  available  about  loading  delays,  aircrew  utilization,  oversize  cargo 
reqitirements,  and  other  factors  limiting  the  availability  of  aircraft  to  perform  airlift  missions  such 
as  sqiport  to  allied  forces,  then  the  model  is  also  able  to  predict  the  size,  composition  of  the  .tirlift 
fleet  needed  and  the  expected  utilization  of  the  fleet 

Ou^r.  The  GAMS  modeling  language*  •:  a  powerful  tool  in  manipulating  and  presenting 
the  mo(tel  solutitxt  GAMS  builds  a  database  of  inftxmation  on  the  model  solution  that  includes 
records  on  each  variable  and  equation  [Brooke  et  al.,  1988;  21].  There  are  four  fields  within  each 
record  which  are  updated  by  GAMS  when  a  solution  is  returned  from  the  solver.  These  fields 
are: 

(1)  lower  b(Hmd  on  variable  or  constraint  right-hand-side; 

(2)  tire  current  (or  (qrtimal)  level  ofthe  variable  or  constraint; 

(3)  iq)per  bound  on  variable  (x*  constraint  right-hand-side;  and 

(4)  the  marginal  (x*  dual  value  ofthe  variable  or  constraint 

GAMS  allows  the  modeler  complete  read-  and  write-access  to  the  database,  making  the 
transformation  and  display  of  the  solution  easier.  For  example,  the  following  information  is 


53 


conq>uted  on  the  ACEP  Oesert  Shield  model  solution  by  manipulating  the  database  (see  Appendix 
F,  ACEP  Desert  Shield  Solution): 

•  PA  VAIL  -  die  maximum  number  of  each  type  of  aircraft  used  at  any  time  during  the 
model  planning  period. 

AAV  AIL  -  the  average  number  of  each  type  of  aircraft  used  during  each  UlE  period. 
MAVAIL  -  the  marginal  value  of  each  aircraft  type  summed  across  die  planning  period. 
PCTHRU/MCTHRU  -  the  maximum  cargo  throughput  used  ^lercent  of  available)  and  the 
aggregated  marginal  value  at  each  on-load  and  off-load  airfield. 

PPTHRU/MPTHRU  -  the  maximum  passenger  throu^ut  used  (percent  of  available) 
and  the  aggregated  marginal  value  at  each  on-load  and  off-load  airfield. 

PMOG/MM(Xj  -  the  maximum  MOG  used  (percem  of  available)  and  the  aggregated 
marginal  value  at  each  airfield. 

TOTAMT  -  total  amount  of  cargo  and  passengers  waiting  for  airlift. 

UTOTAL  -  total  shortfall  in  each  cargo  class. 

DTOTAL  -  total  amount  of  cargo  and  passengers  delivered  over  the  planning  period. 
SORTIES  -  number  of  each  aircraft  type  scheduled  to  begin  an  airlift  mission  on  each  day 
in  the  planning  period  (schedule  of  airlift  missions). 

TOTALS  -  number  of  airlift  missions  performed  by  each  aircraft  type. 

TSORT  -  total  number  of  airlift  missions  performed. 

MIXTURE  -  percent  of  total  number  of  missions  flown  be  each  aircraft  type. 

1 

PERCENT  -  percent  of  total  amount  in  each  cargo  class  delivered  by  each  aircraft  type. 
ACTUTE  -  actual  UTE  rate  achieved  by  each  aiicraf^  type  in  the  solution. 

FLYRATE  -  average  number  of  flight  hours  accumulated  per  day  by  each  aircraft  type. 

This  information  is  very  useful  in  analyzing  the  airlift  problem  and  the  ACEP  solution.  For 
exarrqrle,  the  “fly  rate”  can  provide  valuaWe  information  about|how  well  the  airlift  problem  has 
been  modeled.  The  fly  rate  for  an  aircraft  can  be  defined  as  thej  average  daily  fli^t  time 
accurmilated  by  the  aircraft  actively  participating  in  the  operation.  Fly  rate  is  primarily  a  function 
of  die  routes  and  the  cycle  time.  Comparing  the  ACEP  fly  rate  to  the  actual  average  flight  time  for 
each  aircraft  type  in  Desert  Shield  reveals  how  well  these  aspects  of  the  problem  have  been 
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modeled  Table  20  provides  a  comparison  of  the  fly  rates  in  the  third  (and  most  accurate)  ACEP 
model  to  the  fly  rates  achieved  in  Desert  Shield  In  this  case,  the  fly  rates  of  the  model  solution 
are  craisistently  low,  indicating  that  the  cycle  times  used  on  die  routes  are  too  high.  Howevo*,  a 
non-integer  cycle  time  must  be  used  to  model  the  fly  rates  accurately,  and  a  non-integer  value  for 
dds  parameter  is  not  allowed  in  the  GAMS  model  in:q)lementation.  One  way  to  inpx)ve  the 
accuracy  is  to  use  smaller  units  of  time,  but  this  increases  the  size  of  die  model  dramatically. 


TABLE  20 

Conqiarison  of  Fly  Rates 


Aircraft 

ACEP 

Desert 

Type 

Model 

Shield 

c-y 

9.6 

10.4 

C.141 

10.2 

11.9 

WB 

10.1 

10.7 

NB 

10.3 

11.1 

hi  conclusion,  the  retrospective  test  tqiplied  to  the  ACEP  model  provided  valuable  insight 
into  the  eiqpected  performance  of  the  model  in  a  sustained  airlift  situation.  The  model  is  relatively 
easy  to  buUd  and  solve,  and  solutions  to  the  30-day  proUem  examined  were  computed  relatively 
quickly,  hi  addition,  the  GAMS  modeling  language  provides  a  powerful  medium  for  examining 
the  model  solution.  On  the  odier  hand,  die  accuracy  criteria  specified  by  the  model  sponsor  was 
largely  not  met  with  oily  deliberate  planning  information.  When  the  operational  payload  of  the 
aircraft  can  be  estimated,  then  the  model  may  provide  an  accurate  (within  10  percent)  estimate  of 
the  flow  ctpal^ty  of  the  airlift  system  and  help  identify  and  rank  order  the  botdenecks  in  the 
system.  When  additional  information  is  available,  such  as  loading  delays  and  aircrew  availability, 
then  the  model  may  also  be  able  to  provide  an  estimate  of  the  fleet  size  and  composition.  Specific 
recommendations  on  the  use  of  the  ACEP  model  for  airlift  planning  are  made  in  the  next  chapter. 
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VI.  Recommendations  and  Conclusion 


The  ACEP  model  has  now  been  through  one  full  iteration  of  the  proposed  model 
develqpment  life  cycle.  Many  iterations  may  be  requiied  to  validate  die  model  to  the  sponsor’s 
satis&cticHi,  and  new  iteraticxis  should  be  performed  to  maintain  the  model  However,  if  the 
validation  process  has  been  successful,  tlten  the  model  will  have  already  reached  a  level  of 
maturity  such  tiiat  it  can  make  a  significant  rontribution  to  the  airlift  planning  problem.  To 
conclutte  the  research,  the  validation  paradigm  used  (Ht  the  ACEP  model  is  reviewed  followed  by 
a  summary  of  the  validation  findings.  Specific  recommendations  are  made  on  the  use  of  the 
ACEP  model  for  airlift  planning.  I^ally,  recommendations  for  fiother  research  into  the 
validation  problem  as  well  as  the  airlift  planning  problem  are  given. 

Renew  ofthe  Validation  Paradigm 

The  focus  of  this  research  included  two  main  issues.  The  first  of  the  two  major  problems 
was  to  propose  a  methodology  for  evaluating  the  validity  of  an  existing  model.  The  methodology 
proposed  includes  a  new  model  development  life  cycle  and  techniques  for  ^plying  the  life  cycle 
to  existing  models. 

Overview  of  New  Life  Cycle.  The  model  development  life  cycle  ju’oposed  as  part  of  the 
validation  process  includes  four  stages  which  are  designed  to  provide  a  conuolled  rcansformation 
of  the  model  firom  its  conceptual  form  to  an  operational  form  that  solves  the  “right”  problem.  The 
full  life  cycle  is  shown  once  again  in  Figure  24.  While  maintenance  of  the  model  could  be 
included  as  a  fifth  stage,  it  is  more  proper  to  consider  the  maintenance  process  as  a  microcosm  of 
the  full  life  cycle.  Each  of  the  stages  is  summarized  as  follows: 

(1)  Requirements  Analysis.  The  primary  goal  of  this  stage  is  to  analyze  and  document  the 
problem  or  situation  being  modeled  and  the  model  sponsor’s  requirements  for  solving 
the  problera  The  validation  process  is  started  here  by  establishing  specific  criteria  for 
the  performance  of  the  model  and  identifying  the  post-development  tests  that  will  best 
determine  the  validity  of  the  model. 


Figure  24,  Model  Life  Cycle  Paradigm 


(2)  Model  Design  (formulation).  The  outcome  of  this  stage  of  the  process  is  a  conceptual 
model.  Again,  die  model  design  must  be  documented  to  pmvide  the  necessary 
continuity  in  die  life  cycle  process.  The  conceptual  model  details  the  modeling  approach 
taken  and  the  assunqitions  required  to  use  the  ^iproach. 

(3)  Model  Liqilementadon.  After  the  conceptual  model  has  been  verified  to  meet  the  needs 
of  the  model  sponsor,  it  must  be  implemented  in  an  operadonal  (i.e.  executable)  form. 
The  main  validaticm  goal  of  this  stage  is  to  ensure  that  the  operational  model  is  a  valid 
representation  of  the  conceptual  model. 

(4)  Operational  Validation.  Finally,  the  performance  ofthe  model  on  a  “live”  situation  or  set 
of  data  is  conqiared  to  the  criteria  established  in  the  requirements  analysis  stage.  If  all 
criteria  are  meet,  then  the  model  is  ready  for  use.  Otherwise,  the  life  cycle  is 
backtracked  to  the  point  where  corrections  can  be  made  to  meet  the  criteria. 

This  four-stage  life  cycle  offers  significant  advantages  over  the  traditional  model 
development  approach  discussed  in  Chq)ter  H.  First,  the  model  formulatirai  is  divided  into  two 
distinct  phases  -  analysis  of  requirements  and  model  design.  This  places  more  emphasis  on  the 
investigation  of  requirements  in  the  beginning,  increasing  tite  chances  that  the  operational  model 
will  be  “useful”  to  the  model  sponsor.  Second,  the  results  of  each  stage  of  development  are 
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documented  This  allows  for  a  “face  validation”  of  the  mod  earlier  and  more  often.  In  addition, 
the  transformation  from  conceptual  model  to  operational  model  is  more  controlled  Finally,  the 
documentation  makes  maintenance  and  use  of  the  mod^t  easier  and  an  independent  evaluation  of 
the  model  possible.  The  proposed  life  cycle  can  be  applied  to  existing  models  ^  well. 

Life  Cycle  Recovery  Process,  to  Cht^tter  HI,  techniques  were  presented  for  q)plying  the  life 
cycle  to  models  under  development  or  already  developed  These  techniques  were  used  to  recover 
the  missing  life  cycle  documentation  so  that  the  advantages  of  the  new,  four-stage  life  cycle  could 
be  realized  Three  approaches  were  presented  for  reconstructing  the  missing  life  cycle 
documentation: 

(1)  Starting  the  life  cycle  over  beginning  with  the  analysis  of  requirements  and  ignoring  any 
previous  work  or  existing  models. 

(2)  “Backing  in”  to  the  missing  documentation  based  upon  the  existing  model  and  making 
changes  identified  through  interaction  with  the  model’s  sponsor. 

(3)  A  combination  of  both  approaches. 

The  primary  lesson  of  the  research  is  that  validation  of  models  is  a  difftcult  and  tedious 
process  and  cannot  be  totally  separated  fiom  the  development  life  cycle  of  the  model.  Thus,  the 
only  hope  in  conducting  an  independent  evaluation  of  a  model  is  to  Lave  (or  recreate)  documented 
model  requirements  proved  by  the  model  sponsor,  a  written  formulation  that  explains  how  the 
requirements  are  met  in  conceptual  form,  an  operational  model  verified  to  correctly  implement  the 
formulation,  and  the  results  of  any  previous  post-development  validation  tests  performed. 

Summary  of  ACER  Validation  Findings 

TTie  ACEP  model  proposed  by  Oak  Ridge  National  Labwatory  provided  a  good  case  study 
of  the  life  cycle  recovery  process.  The  results  of  each  stage  of  the  methodology  used  to  validate 
the  model  are  summarized  as  follows: 

(1)  Recovery  of  Model  Requirements.  Model  requirements  were  develq)ed  by  backing 
into  a  requirements  document  and  making  the  changes  requested  by  the  model  sponsor 
at  AMC.  Additional  constraints  to  account  for  airfield  working  MOG  and  aircraft  UTE 
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were  added  to  the  model  as  a  result  of  the  requirements  analysis  process.  In  addition, 
specific  validation  criteria  were  established. 

Model  Inq)lcmentatioa  The  GAMS  operational  model  was  validated  using  three 
techniques  collectively  called  “constraint  validation”.  These  include  the  development  of 
a  contrived  scenario,  the  examination  of  the  effect  of  individual  constraints,  and  the  use 
of  alternative  objective  functions.  Improvements  made  to  the  ACEP  model  as  a  result  of 
tile  ccxistraint  validation  process  include  modifications  to  the  objective  hinction  to 
minimize  closure,  additional  constraints  to  enforce  aircraft  UTE  and  availability  by 
qierating  base  as  well  as  across  aircraft  types,  an  additional  constraint  to  offset  the 
model’s  natural  tendency  to  favor  the  delivery  of  passengers  over  cargo,  and  improved 
presentation  of  the  optimal  soloution. 

(3)  Post- Validation  Test  The  retrospective  test  used  “live”  data  from  the  Operation  Desert 
Shield  airlift  to  provide  further  insight  into  the  validity  of  the  model.  During  the  test,  the 
model  solution  was  compared  to  the  Desert  Shield  airlift  in  terms  of  the  model  objective 
function,  the  amount  of  cargo  and  number  of  passengers  delivered  over  30  days,  the 
number  of  airlift  missions  performed,  the  average  number  of  aircraft  used,  and  the 
contribution  of  each  type  of  aircraft  to  the  total  result  It  was  discovered  that  the  model 
can  estimate  the  flow  ct^ability  of  a  Desert  Shield-type  operation  within  the  required 
tolerance  as  long  as  the  model  is  built  using  an  estimate  of  the  “operational”  payloads  of 
the  aircraft  In  additicHi,  the  identification  of  airfield  bottlenecks  seemed  to  be  accurate. 
On  tite  other  hand,  the  optimal  aircraft  fleet  size  and  conq)osition  found  by  the  model 
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diftoed  significantly  from  the  fleet  used  in  Desert  Shield.  A  number  of  factors  were 
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found  which  could  explain  the  difference  -  such  as  the  hi^  percentage  of  oversize  cargo 
which  could  not  be  carried  by  CRAF  aircraft.  Some  of  the  factors  which  were  used  to 
eiqilainme  difference  required  information  that  would  be  available  only  during  execution 
planning  of  an  airlift. 

As  a  result  of  the  validation  findings,  the  model  has  been  improved.  While  the  Desert  Shield 
scenario  is  not  ideal  for  demonstrating  all  of  the  improvements  made,  the  new  ACEP  model 
solution  is  closer  to  the  actual  airlift  than  the  original  model  solution,  as  shown  in  Figures  25  and 
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Figure  25.  Comparison  of  Amount  Delivered  (AH  Models) 


Figure  26.  Summary  of  Aircraft  Utilization  (All  Models) 


26.  In  addition,  the  mode!  output  has  been  improved  to  provide  much  more  concise  and  useful 
information  about  the  model  solution,  making  analysis  of  the  solution  easier. 


Recommendations  for  Use  of  the  ACEP  Model 

The  ACEP  model  was  tested  against  one  of  the  largest,  most  difficult  airlift  operations  in 
history.  However,  massive,  sustained  airlift  (derations  like  Desert  Shield  have  occuired  only 
once  every  40  years  or  so.  Consequently,  the  model  should  be  tested  against  more  mundane, 
day-to-day  airlift  scenarios  before  receiving  full  accreditation  for  use  on  the  airlift  problem. 
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In  addition,  the  two  modes  of  airlift  planning  -  deliberate  and  execution  -  have  different 
and,  in  many  ways,  incompatible  requirements.  Since  the  ACEP  model  was  developed  with  both 
modes  in  mind,  some  compromises  had  to  be  made.  Based  on  this  research,  the  recommended 
uses  of  the  ACEP  model  as  it  currently  stands  are: 

(1)  Deliberate  planning.  The  model  should  provide  reliable  results  in  identifying  the  most 
critical  airfield  bottlenecks  in  a  given  airlift  system.  In  addition,  the  model  may  be 
q}prq)riate  for  conducting  flow  c^aMity  studies  or  transportation  feasiWity  studies 
where  the  size  and  composition  of  the  aircraft  fleet  to  be  used  are  known  or  estimated. 
Whenever  possible,  and  particularly  when  CRAF  aircraft  are  involved,  the  oversize 
cargo  category  should  be  included  in  the  model  to  increase  accuracy. 

(2)  Execution  planning.  The  model  seems  to  have  tiie  greatest  unrealized  potential  in  this 
mode  of  planning.  Given  that  the  operational  payloads  o^  the  aircraft  can  be  estimated 
accurately  and  that  aircrew  utilization  factors  can  be  accaonted  for,  then  the  model  may 
be  used  to  determine  fleet  size  and  composition  requirements.  The  primary  limiting 
factor  is  the  effort  required  to  find  an  optimal  solution  as  the  problem  size  increases. 

Recanmendadons  for  Bather  Research 

The  life  cycle  paradigm  of  modeling  is  not  well  developed  and  requires  further  research  to 
teach  the  mature  paradigm  available  in  other  engineering  fields  -  such  as  software  engineering. 
Some  specific  recommendations  for  further  research  into  the  life  cycle  process  are: 

(1)  Develop  alternatives  to  the  "waterfall”  life  cycle.  In  software  engineering  several 
alternative  life  cycles  have  been  identified  that  buUd  upon  the  basic  “waterfall”  life  cycle 
and  may  be  more  appropriate  under  certain  circumstances.  Examples  include: 

•  the  “rapid  prototyping”  life  cycle  which  is  used  when  the  requirements  for  the 
software  are  not  well  understood.  This  life  cycle  focuses  the  iiutial  effort  on 
developing  a  prototype  of  the  envisioned  system  for  the  purpose  of  investigating 
further  the  user’s  true  needs. 

•  the  “evolutionary”  life  cycle  where  the  software  is  developed  in  increments  or 
phases. 
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These  alternative  life  cycle  approaches  seem  particularly  applicable  to  modeling  and 
may  be  mote  appropriate  than  the  classic  “waterfall”  approach. 

(2)  Documentation  standards  and  configuration  management  As  mentioned  in  Cht^ter  n 
these  topics  have  received  a  great  deal  of  attention  in  the  software  engineering  field,  but 
almost  none  in  computer  modeling.  Some  specific  questions  that  might  be  addressed 
include: 

•  Which  models  need  to  go  through  the  rigorous  life  cycle  process?  If  the  model’s 
intended  use  is  veiy  limited,  then  certainly  the  need  for  a  rigorous,  documented 
process  could  be  questioned. 

•  What  should  be  documented  in  each  stage  of  the  life  cycle  and  how  are  die 
documents  updated  when  a  change  is  made  to  the  model? 

•  How  much  should  the  model  sponsor  be  involved  in  each  stage  of  the  life  cycle? 

The  ACEP  validation  effort  has  also  yielded  some  areas  where  further  research  on  the 

modelmg  and  solution  approaches  seems  warranted.  These  are: 

(1)  In  Cluster  V  it  was  discovered  that  non-integer  cycle  times  on  the  routes  may  result  in  a 
more  realistic  modeling  of  the  delays  associated  with  post-mission  aircraft  maintenance 
and  crew  rest  The  model  should  be  modified  to  allow  airlift  planners  to  use  non-integer 
cycle  times. 

(2)  AMC  should  consider  splitting  the  model  into  two  models,  each  developed  further  to 
meet  the  needs  of  the  two  types  of  airlift  planning  -  deliberate  and  execution.  The 
current  ACEP  model  was  developed  for  both  situations  and  is  a  compromise  of  the 
needs  of  the  two  modes  of  operation. 

(3)  The  model  could  be  modified  to  include  the  “direct  delivery”  concept  that  has  been 
identified  by  many  as  the  primary  advantage  of  the  new  C-17  aircraft  (see  Cooke,  1984; 
Miller,  1988;  Streater,  1988;  Ulsamer,  1984).  This  model  must  incorporate  the 
Required  Delivery  Date  (RDD)  and  account  for  the  travel  time  between  the  off-load 
airfield  and  the  final  destination  of  the  passengers  and  cargo  (Appendix  A,  Section  5.2). 

(4)  As  mentioned  in  Chapter  H,  other  heuristic  techniques  for  finding  good,  integer 
solutions  should  be  investigated.  Some  techniques  from  the  literature  which  seem 
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espcd2iSly^OTrma%2Jtsimdatedamealmg2ixid.U^rmffanTelaxaiion.  These 
techniques  offer  efficient  solution  algorithms  for  finding  integer  solutions  to  large 
problems  in  a  reasonable  amount  of  time. 
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Appendix  A:  Model  Requirements  SpeciScadon  for  the 
Airlift  Crpabilities  Estimation  Prtxotype  (ACBP) 


1.0  OVERVIEW 

TTie  Airiift  Capabilities  Estimation  Prototype  (ACEP)  is  a  deterministic  model  that 
provides  rough  estimates  of  the  resources  need^  to  perform  an  airlift  operatioa  The  ACEP 
model  is  used  in  two  modes:  (1)  during  the  early  stages  of  deliberate  planning  when  only 
iq)proximate  information  on  the  moUlity  requirements  is  available  and  the  response  time  of  the 
model  is  not  critical;  and  (2)  during  execution  planning  to  obtain  quick  estimates  of  resources 
afto*  a  modification  of  moiety  teqiurements.  In  the  second  mode,  the  response  time  of  the 
model  is  critical  The  output  of  the  model  is  used  for  further  planning  or  as  the  initial  estimate 
of  resources  required  to  start  mwe  detailed  analysis  of  the  problem, 

2.0  APPUCABLE  DOCUMENTS 

2.1  APR  28-3,  USAF  Operations  Planning  Process. 

2.2  Busch,  BigridK.  and  Michael  R.  Hilliard.  An  Airlift  Capatdlities  Estimation  Model 
for  the  Military  Airiift  Problem.  Operations  Research  Group,  Center  for  Transportation 
Analysis,  Oak  Ridge  National  LabOTatory,  1992. 

2.3  Gearing,  Capt  Rick,  and  Maj  Jim  Hill  “UTE  Rates  Revisited,”  AtliA  18-21 
(Spring  1988). 

2.4  Ifilliard,  Michael  R.,  Rajendra  S.  Solanki,  Cheng  Uu,  Ingrid  K.  Busch,  Gleu 
Harrison,  and  Ronald  D.  Kraemer.  “Scheduling  the  Citation  Desert  Storm  Airlift:  An 
Advanced  Automation  Scheduling  Support  System,”  Interfaces,  22:  131  -146(1992). 

25  MAC  Regulation  55-28. 

2.6  Snuth,  Maj  Ronny  C,  “Station  CapaWlity,”  Airiiti:  14- 16  (Winter  1985). 

3.0  PROBLEM  SUMMARY 

The  airlift  planning  problem  can  be  described  as  follows:  it  is  desired  to  transport  a 
known  amount  of  cargo  and  passengers  ftom  a  set  of  on-load  airfields,  through  a  sequence  of 
enroute  airfields,  to  one  or  more  off-load  airfields  within  a  specified  amount  of  time.  A  fleet  of 
heterogeneous  aircraft  is  assigned  to  perform  the  airlift,  and  a  set  of  possible  routes  to  move  the 
cargo  fix>m  origins  to  destinations  is  available.  There  are  many  conflicting  objectives  and 
constraints  in  the  problem  and  many  formulations  are  possible.  In  addition,  problems  of 
practical  size  and  importance  involve  dozens  of  airfields,  hundreds  of  movement  requirements 
and  aircraft,  and  span  over  a  planning  horizon  of  90  days  or  more,  making  the  resulting 
problem  difficult  to  solve. 

4.0  MODELING  OBJECTIVE 

The  primary  objective  of  the  ACEP  model  is  to  obtain  reasonable  estimates  of  the  number 
and  type  of  aircr^  needed  to  perfOTm  a  specific  airlift  operation.  In  addition,  the  model  should 
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be  able  to  identify  bottlenecks  in  the  airlift  system  that  are  the  limiting  factors  in  achieving  an 
optimal  flow  of  cargo  and  passengers  throu^  the  system. 

4.1  PRIMARY  OPTIMIZATION  GOALS. 

The  primaiy  t^timization  goal  of  the  ACEP  model  is  to  minimize  shortfall  -  the  amount  of 
cargo  and  passengers  left  undelivered  at  the  end  of  a  specific  planning  period. 

42  SECONDARY  OPTIMIZATrON  GOALS. 

Of  sectHidary  c(»ican  to  minimizing  undelivered  cargo  is  the  efficiency  of  the  operation. 
Die  model  should  attenqit  to  develop  an  airlift  schedule  which  minimizes  cost  and  maximizes 
resource  utilizatioa  Other  desirable  goals  are: 

•  Deliver  each  movement  requirement  as  early  as  possible; 

•  Minimize  the  number  of  aircraft  used;  and 

•  Maximize  aircraft  utilization  (within  limits). 

5.0  MODELING  CONSTRAINTS 

There  are  both  spacial  and  temporal  constraints  that  effect  the  number  of  aircraft  required 
and  the  scheduling  strategy  used  to  employ  the  aircraft.  A  discussion  of  these  constraints 
follows. 

5.1  PLANNING  HORIZON 

Normally,  an  airlift  operation  spans  a  given  planning  period  or  horizon.  At  the  end  of  the 
period  all  movement  requirements  should  be  delivered  to  the  ^propriate  destination.  Any 
undelivered  cargo  or  passengers  at  the  end  of  the  period  is  shortfall. 

52  MOVEMENT  REQUIREMENTS 

The  cargo  to  be  moved  can  be  classified  into  four  categories:  outsit,  oversize,  and  bulk 
cargo,  and  passengers.  Outsize  cargo  is  equipment  too  large  and  heavy  to  be  carried  by  any 
airoaft  in  die  Air  Force  inventory  except  the  C-5  (and  the  C-17  when  it  becomes  available).  An 
example  of  outsize  cargo  is  the  Bradley  armored  personnel  carrier.  Oversize  cargo  includes 
equipment  such  as  a  2  J-ton  truck  that  is  too  large  for  standard-size  pallets.  Bulk  cargo  is 
everything  else  which  can  be  consolidated  onto  standard-size  pallets.  The  deployment  of 
military  units  normally  requites  the  movement  of  a  mixture  of  cargo  types  and  passengers. 

Cargo  and  passengers  fixrm  the  various  units  being  moved  can  only  be  picked-up  and 
delivered  during  certain  time  windows  (Figure  27).  The  earliest  time  that  a  payload  may  be 
loaded  onto  an  aircraft  at  the  on-load  airfield  is  caUed  the  avaUaUe-to-load  date  (ALD).  This 
date  is  determined  by  the  military  unit  to  which  the  cargo  or  passengers  are  assigned.  The 
earliest  time  that  die  payload  can  arrive  at  the  off-load  airfield  is  called  the  earliest  arrival  date 
(EAD).  The  latest  anival  date  (LAD)  is  the  latest  time  that  the  payload  can  arrive  at  the  off-load 
airfield.  These  times  are  determined  by  the  commander  of  the  operation.  Rnally,  each 
requiiement  may  have  a  requited  delivery  date  (RDD)  which  is  the  deadline  for  arrival  of  the 
requirement  at  its  final  destination  within  the  theater  of  operation  [Hilliard,  et  al.,  1992: 133]. 

Past  airlift  tolerations  in  support  of  contingencies  have  shown  that  approximately  one  ton 
of  cargo  must  be  delivered  for  each  passenger.  This  is  not  true  of  all  airlift  scenarios. 
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Earliest  Arrival  Latest  Arrival 
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Figure  27.  Airlift  Planning  Temporal  Constraints 


5.3  AVAILABLE  ROUTES 

Many  possible  routes  may  be  available  for  the  aircraft  to  move  the  requirements  fiom  the 
on-load  airfields  to  the  off-load  tdrfields.  However,  the  number  of  practic^  routes  available  is 
usually  limited  and  these  routes  can  be  enumerated.  This  makes  the  problem  much  easier  to 
solve  from  a  modeling  perspective.  An  ideal  route  \wll  start  at  die  aircraft’s  home  base  (Figure 
28).  The  aircraft  will  on-load  the  cargo  or  passengers  at  the  airfield  nearest  to  the  origin  of  the 
cargo  or  passengers  and  fly  as  direct  as  possible  to  the  off-load  airfield.  A  stop  at  one  or  more 
enroute  aMelds  may  be  required  to  refuel  or  change  crews.  The  off-load  airfield  is  located  as 
close  as  possible  to  the  final  destination  of  the  cargo  or  passengers.  A  recovery  base  is  often 
used  for  refueling  and  maintenance  purposes  to  ease  the  congestion  at  the  off-load  airfields. 
Then  the  aircraft  returns  to  its  home  base  to  prepare  for  the  next  mission. 


5.4  ENROUTE  SUPPORT  AND  STATION  CAPABILITY 

The  on-Ioad,  off-load  and  enroute  airfields  have  varying  capability  to  support  visiting 
aircraft.  The  on-load  and  off-load  airfields  are  limited  in  the  amount  of  cargo  and  passengers 
that  can  be  processed  through  the  field  each  day  (called  throughput).  The  throughput  limit  is 
dependent  upon  factors  such  as  the  capacity  of  the  passenger  terminal  and  the  number  and  type 
of  material  handling  equipment  (MHE)  available.  The  MHE  is  required  to  load  and  unload 
cargo  from  the  aircraft. 
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All  of  the  airfields  involved  in  the  airlift  flow  are  limited  in  the  number  of  aircraft  that  can 
be  siq)ported  at  a  given  time.  The  myriad  of  factors  involved  in  determining  this  limit  are  often 
aggregated  into  a  single  constraint  called  maximum  on  the  ground  (MOG).  MOG  is  defined  in 
MAC  Regulation  SS-28  as  “the  highest  number  of  aircraft  being  used  in  an  (^ration  which  will 
be  allowed  on  the  ground  during  a  given  span  of  time  based  on  simultaneous  suppmt”. 

Analysts  refer  to  two  different  types  of  in  planning  airlifts.  The  ramp  space  available  to 
park  aircraft  is  called  “parking  MOG”.  All  other  aircraft  servicing  ctmstraints  are  included  in 
die  “working  MOG”.  A  number  of  diverse  factors  contribute  to  die  working  MOG  at  a 
particular  airfield  and  point  in  time.  Typically  the  most  important  factor  is  the  refueling 
capability  of  the  airfield.  The  most  constraining  of  the  two  types  of  MOG  -  parking  and 
working  -  is  the  limiting  factor  in  sigiporting  an  airlift  operation.  MOG  for  a  particular  airlift 
operation  at  an  airfield  is  also  effect^  by  odier  enroute  trafBc  the  airfield  must  support 
simultaneously  [Smith,  1985]. 

5.5  AIRCRAFT  CONSTRAINTS 

Size,  capacity  and  maneuverability  contribute  to  the  amount  of  MOG  used  by  a  particular 
type  of  aircrt^  Other  airlift  planning  factors  associated  with  the  aircraft  used  are  [Hilliard  et 
al.,  1992: 132  - 137]; 

(1)  Each  type  of  aircraft  has  a  limited  capacity  for  each  type  of  cargo,  and  some 
aircraft  may  be  unable  to  carry  some  types  of  cargo. 

(2)  The  flow  planners  may  specify  a  mini  mum  load  required  to  justify  a  mission. 

(3)  Each  type  of  aircraft  has  a  cargo  type  for  which  it  is  best  suited  to  carry  (called 
its  piefbned  cargo  type). 

(4)  Certain  aircraft  may  have  special  capabilities  which  can  be  used  to  improve  the 

airlift  flow.  For  example,  C-5  aircraft  are  capable  of  carrying  as  many  as  75 
passengers  in  addition  to  any  cargo  carried  is  caUed  a  non-preferred  cargo 

type). 

Finally,  the  aircraft  must  not  be  over-utilized.  Air  Force  planners  aggregate  all  the  factors 
that  limit  the  utilization  of  aircraft  into  a  number  called  the  Ul^  rate.  UTE  rate  can  be  defined 
as  the  total  pool  of  daily  flying  hour  capability  for  a  fleet  of  (homogeneous)  aircraft  distributed 
equally  by  each  primary  aircraft  authorization  [Gearing  and  Hill,  1988: 18^  Three  types  of 
UTE  rates  are  commonly  used:  peacetime,  objective  wartime,  and  obtainable  wartime.  The 
peacetime  UTE  rate  is  based  solely  upon  the  flying  hours  qiproved  by  Congress  in  the  annual 
budget  The  otgective  wartime  UTE  rate  corresponds  to  tiie  capalnlity  that  planners  would  like 
to  achieve  in  wartime.  ObtainaUe  wartime  rates  are  the  actual  airlift  capabilities  experts  believe 
can  be  achieved  for  a  particular  wartime  scenario  and  set  of  resources.  Objective  and  obtainable 
UTE  rates  are  expressed  for  both  surge  (first  45  days)  and  sustained  (after  45  days)  periods. 

Four  factors  are  used  to  determine  the  obtainable  wartime  UTE  rates  for  various  aircraft: 
aircrew  manning,  maintenaiKe  manning,  spare  parts,  and  the  airlift  system.  The  UTE  rate  that 
is  most  constraining  is  used  as  the  estimate  for  deployment  capability  and  included  in  the  Joint 
Strategic  Capabilities  Plan  (JSCP).  The  JSCP  reports  four  UTE  rates  for  a  given  aircraft  type 
and  scenario.  A  UTE  rate  is  calculated  for  three  divisions  within  the  surge  period  (the  first  45 
days  of  an  operation)  beginning  with  C-day  (the  day  deployment  begins)  and  an  overall  surge 
rate  is  calculated  as  follows  (Figure  29): 

(1 )  C-day  throu^  C-day  +  2.  UTE  rate  starts  low  and  builds  quickly  to  a  high 
value  reflecting  the  generation  of  aircraft  into  the  airlift  operation. 

(2)  C-day  +  3  through  C-day  +  15.  Aircraft  are  assumed  to  surge  to  the  objective 
UTE  rate  due  to  the  critical  nature  of  the  early  deployment  period. 

(3)  C  +  16  through  C  +  45.  A  pool  of  flying  hours  is  calculated  which  is  the  total 
hours  an  aircraft  can  fly  in  the  45  days  of  surge  minus  the  hours  already  flown. 


67 


(4)  An  overall  UTE  rate  for  the  surge  period  is  also  reported  (the  time  average  of 
the  UTE  rate  for  each  day). 

UTE  rates  are  not  meant  to  be  a  constraint  during  an  actual  deployment  If  higher  UTE 
rates  can  be  achieved,  then  they  will  be.  But  the  published  UTE  rates,  developed  by  experts 
using  historical  data  and  computer  models,  represent  the  hipest  expected  utilization  rates  that 
can  be  achieved  [Gearing  and  HU,  1988:21]. 

6.0  MODEL  INPUT 

AU  input  to  the  model  wiU  be  iiKluded  in  the  model  formulation  or  wiU  be  contained  in 
separate  files  buUt  using  any  ASCII  editor.  AU  input  parameters  should  be  consistent  in 
dimension  (same  order  of  magnitude)  to  obtain  reUable  results.  Specific  input  requirements  are 
Usted  next. 

6.1  PLANNING  HORIZON 

The  planning  horizon  of  the  model  wiU  be  divided  into  equal  time  periods.  In  general,  the 
time  peri^  used  determines  both  the  size  of  the  model  that  must  be  solved  and  the  accuracy  of 
the  results.  A  smaUer  unit  of  time  (e.g.  one  time  unit  equals  one  hour)  wUl  result  in  a  larger 
model  with  very  detailed  results.  A  larger  unit  of  time  (e.g.  one  time  unit  equals  one  day)  wiU 
result  in  a  more  tractable  model,  but  the  results  wiU  be  less  meaningful.  Thus  choosing  the 
time  unit  to  use  will  require  a  trade-off  between  the  level  of  detail  desired  and  the  response  time 
required. 

6.2  MOVEMENT  REQUIREMENTS 

Information  on  the  movement  requirements  includes: 

(1)  number  of  military  units  being  moved; 

(2)  on-load  station  for  each  unit; 

(3)  off-load  station  for  each  unit; 

(4)  amount  to  be  moved  in  each  cargo  class; 


68 


/ 


(5)  pickup  window  for  each  unit’s  requirements;  and 

(6)  priority  ranking  of  the  units  (optional). 

6.3  ROUTE  INFORMATION 

Each  route  will  be  described  as  follows: 

(1 )  a  sequence  of  airfields  from  aircraft  home  field  to  omload,  throu^  enroute 
airfields  to  off-load,  and  back  to  the  aircraft  home  field; 

(2)  die  fli^t  time  of  each  route  leg  (hours  required  to  fly  £rem  one  base  in  the 
sequence  to  the  next); 

(3)  the  e}q)ected  ground  time  at  each  of  the  on-load,  enroute,  and  off-load  airfields; 

(4)  die  cycle  time  for  each  type  of  aircraft  on  the  route.  Cycle  dme  is  defined  to  be 
the  time  required  for  a  particular  aircraft  type  to  fly  the  route  from  home  field,  to 
on-load,  enroute,  and  off-load  airfields,  and  back  to  home  field.  Any  delay 
associa^  with  post-mission  maintenance  or  crew-rest  is  added  to  the  cycle  time 
such  that,  at  the  end  of  the  time,  the  aircraft  is  ready  to  perform  a  new  mission. 

6.4  AIRFIELD  PARAMETERS 

For  each  on-load  and  off-load  airfield  a  throughput  limit  will  be  input  for  each  time  period 
of  the  model.  In  addition,  both  parking  and  working  MCXI  limits  will  be  input  for  each  on¬ 
load,  off-load,  and  enroute  airfield  in  the  model.  ! 

6.5  AIRCRAFT  CHARACTERISTICS  | 

the  following  information  on  the  aircraft  used  in  the  airlift  ^  be  input: 

(1)  types  avjdlable;  I 

(2)  number  of  each  type  of  aircraft  available  at  each  home  (operating)  airfield  during 
each  time  period; 

(3)  cycle  time  for  each  aircraft  type  on  each  possible:  route  (see  section  6.3); 

(4)  MCXj  used  by  each  type  of  aircraft;  | 

(5)  capacity  of  each  type  of  aircraft  for  its  preferred  cargo  type; 

(6)  edacity  of  each  t}^  of  aircraft  for  its  non-prefei^  cargo  type  (if  applicable); 

ar^  I 

(7)  the  appr(q)riateUTE  rate  for  each  aircraft  type  and  surge  period.  UTE  rates  may 
also  be  enforced  for  a  particular  group  of  aircraft  within  each  type.  For 
exanq;le,  the  utiliaation  of  aircraft  from  a  particular  unit  or  base  may  be 
constrained  to  prevent  over-utilization. 

7.0  MODEL  OUTPUT 

The  output  fiom  the  model  will  consist  of  a  printed  solution  identifying  the  optimal 
mission  schedule,  number  and  mix  of  aircraft  used,  and  any  shortfall. 

7.1  AIRCRAFT  AND  MISSION  INFORMATION 

Themodel  will  report  optimal  values  of  two  primary  decision  variable  types.  Rrst,the 
shmtfall  for  each  unit  and  cargo  class  will  be  reported.  Second,  a  flow  variable  for  each 
aircraft  type,  cargo  type,  and  time  period  will  be  reported.  This  flow  variable  represents  the 
number  of  missions  scheduled  by  the  model  to  start  in  each  time  period. 
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72  BOTTLENECK  AND  SENSITIVITY  INFORMATION 

Information  on  the  sensitivity  of  the  optimal  solution  to  changes  in  the  input  parameters 
will  be  available  including: 

(1)  the  sensitivity  of  the  solution  to  changes  in  the  “cost”  of  using  a  particular 
aircraft  or  of  shortfalling  a  particular  unit’s  movement  requirements;  and 

(2)  infcnmation  on  which  of  the  constrained  resources  (aircr^  and  airfields)  is  most 
critical  and  should  be  the  focus  of  any  effort  to  add  resources  to  improve  the 
airlift  flow. 

7.3  POST-PROCESSING 

A  wide  range  of  post-processing  will  be  available  after  the  optimal  solution  is  found 
including: 

(1 )  collecting  mission  information  on  like  aircraft  to  report  a  schedule  of  missions  to 
be  flown  by  aircraft  type; 

(2)  calculating  the  total  number  of  inissions  scheduled; 

(3)  reporting  the  composition  of  the  aircraft  fleet  used;  and 

(4)  ctdculating  other  comparative  statistics  such  as  ton-miles  or  utilization. 

8.0  MODEL  VALIDATION 

The  model  will  not  be  useful  unless  it  can  routinely  provide  reasonably  accurate  solutions 
in  a  timely  manner.  The  following  criteria  and  tests  will  be  used  to  judge  the  validity  of  the 
model  developed. 

8.1  VALIDATION  CRITERIA. 

As  mentioned  in  the  overview,  the  model  may  be  used  in  two  different  situations.  First, 
the  model  may  be  used  in  the  early  stages  of  delib^e  planning,  lii  this  situation,  the 
information  available  as  input  to  the  model  is  approximate,  and  the  response  time  of  the  model 
is  not  critical.  The  second  situation  is  the  more  demanding  on  the  model.  In  this  situation,  the 
model  is  used  for  execution  planning,  when  the  response  time  is  critical.  Consequently, 
validation  criteria  will  be  used  to  satisfy  the  more  demanding  situation  where  the  model  is  used 
to  help  in  die  execution  planning  process  as  follows: 

(1 )  Ease  of  use.  Information  that  is  required  for  input  to  the  model  must  be  easily 
obtainable  fi-om  sources  already  available  in  the  planning  process  and  not 
require  extensive  transformations  prior  to  input. 

(2)  Response  time.  The  model  must  be  able  to  compute  a  solution  to  a  problem  of 
realistic  size  within  a  reasonable  amount  of  time.  While  any  quantification  of 
this  criteria  is  purely  arbitrary,  a  reasonable  goal  may  be  to  provide  a  solution  to 
a  30  day  planning  problem  within  30  minutes  of  clock  time  on  a  VAX 
minicomputer. 

(3)  Accuracy.  The  model  must  be  able  to  determine  the  resources  required  to 
perform  an  airlift  flow  within  plus  or  minus  10  percent  of  the  actual 
requirements. 

(4)  Output  The  output  fi-om  the  model  must  clearly  state  the  optimal  resource 
requirements,  expected  shortfalls,  and  sensitivity  information. 


S2  VALIDATION  STEPS. 

Validation  of  the  model  will  be  performed  in  two  primaiy  ways. 

(1)  Face  Validation.  Rrst,  this  specification  will  be  reviewed  by  experts  (airlift 
flow  planners)  to  determine  if  it  adequately  represents  the  problem.  Also,  the 
model  will  be  solved  using  a  typical  scenario  and  the  results  will  again  be 
scrutinized  by  experts.  These  steps  are  performed  to  compare  the  model  against 
validation  criteria  items  (1),  Ease  of  use,  and  (4),  Ouqrut. 

(2)  Second,  historical  data  from  a  significant  airlift  qreration  already  performed  will 
be  processed  through  the  model  This  step  is  perfoined  to  compare  the  model 
against  validation  criteria  (2),  Response  time,  and  (3),  Accuracy. 
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Appendix  B:  Design  Document  fa- the 
AMift  Capabilities  Estimation  Prototype  (ACEP) 

1.0  OVERVIEW 

The  Airlift  Capabilities  Estimation  Prototype  (ACEP)  model  is  a  deterministic  model  that 
provides  rou^  estimates  of  the  resources  needed  to  perform  an  airlift  operation.  The  original 
formulation  was  developed  by  Ingrid  K.  Busch  and  Michael  R.  Hilliard  of  the  Operations  Research 
Group,  Center  for  Transportation  Analysis,  Oak  Ridge  National  Laboratory.  This  design 
document  is  based  upon  iqrdated  model  requirements. 

2.0  APPUCABLE  DOCUMENTS 

2.1  Busch,  Ingrid  K.  and  Michael  R.  Hilliard.  An  AirM  Capabilities  Estimation  Model  for 
the  Mlitary  Airlift  Problem.  Operations  Research  Group,  Center  for  Transportation  Analysis,  Oak 
Ridge  National  Laboratory,  19%. 

2.2  Model  Requirements  Specification  for  the  Airlift  Capacities  Estimation  Prototype,  1992. 
3.0  PROBLEM  SUMMARY 

The  airlift  planning  problem  can  be  described  as  follows:  it  is  desired  to  transport  a  known 
amount  of  cargo  and  passengers  from  a  set  of  on-load  airfields,  through  a  sequence  of  enroute 
airfields,  to  one  or  more  off-load  airfields  within  a  specified  amount  of  time.  A  fleet  of 
heterogeneous  aircraft  is  assigned  to  perform  the  airlift,  and  a  set  of  possible  routes  to  move  the 
cargo  fipom  origins  to  destinations  is  available.  There  are  many  conflicting  objectives  and 
constraints  in  the  problem  and  many  formulations  are  possible.  In  addition,  problems  of  practical 
size  and  importance  involve  dozens  of  airfields,  hundreds  of  movement  requirements  and  aircraft, 
and  span  over  a  planning  horizon  of  90  days  or  more,  making  the  resulting  model  computationally 
difficult  to  solve. 

4.0  OVERVIEW  OF  MODEUNG  APPROACH 

A  linear  programming  approach  is  taken  so  that  the  model  may  provide  an  optimal  solution 
while  remaining  flexible  and  fast  Non-integer  solutions  are  expected,  but  because  the  model  is 
used  only  to  obtain  very  rough  estimates  of  resource  requirements,  tiiis  is  xceptable.  Depending 
upon  how  the  mottel  is  implemented  and  the  speed  of  the  linear  program  (LP)  solver  used,  the 
model  has  the  potential  to  be  very  flexible.  Once  a  solution  is  found  for  a  particular  set  of  inputs, 
changes  can  be  made  to  the  data  and  the  model  can  be  restarted  from  a  previous  solution.  An 
additional  advantage  of  the  linear  programming  approach  is  that  requir^  sensitivity  analysis 
information  is  automatically  calculated. 

5.0  MODEL  ASSUMPTIONS 

Some  assumptions  are  required  in  order  to  use  a  linear  programming  approach.  Most 
notably,  it  is  assumed  that  the  non-integer  (i.e.  infeasible)  solution  can  be  used  to  provide  the 
decision  information  required.  Some  other  assumptions  that  are  made  are: 

(1)  The  objective  function  and  constraints  in  the  problem  can  be  modeled  with  linear 
equations.  The  classic  assumptions  of  linear  programming  are: 
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•  ptoponiffliality  -  the  contribution  of  each  decision  variable  is  proportional  to  the  value 
of  the  variable. 

•  additivity  -  the  contribution  of  each  variable  is  independent  of  the  values  of  the  other 
vaiiaUes. 

•  divisibility  -  the  decision  variables  are  allowed  to  take  on  non-integer  values. 

•  certainty -each  parameter  in  the  problem  is  known  with  certainty. 

•  nonnegadvity  -  ^  decision  variables  are  restricted  to  values  greater  than  or  equal  to 
zero. 

(2)  Non-preferred  cargo  carried  by  aircraft  will  be  of  type  ‘  bulk”  or  “passengers”  only.  It  is 
unlikely  that  any  aircraft  type  will  be  able  to  carry  “outsize”  cargo  in  a  non-preferred 
capacity. 

(3)  Aircraft  are  assumed  to  “consume”  both  parking  and  working  MOG  at  each  airfield  in 
proportion  to  the  size  of  the  aircraft  and  the  number  being  serviced.  For  example,  if  a 
sin^e  C-141  is  considered  to  take  1.0  unit  of  MOG,  then  two  C-141s  will  take  2.0  units. 

6.0  MATHEMATICAL  FORMULATION 

The  mathematical  formulation  presented  here  is  based  iq}on  the  formulation  of  Busch  and 
Ifilliard  with  additions  and  modifications  where  nece^aiy  to  meet  the  model  specifications. 

6.1  PARAMETERS 

The  following  symbols  are  used  to  represent  model  parameters  or  input  datii: 

b  is  the  set  of  airfields  (on-load,  enroute,  and  off-load)  considered  in  the 
model 

r  is  the  set  of  routes  available  from  on-load  airfields  to  off-load  airfields. 

t  is  the  planning  horizon  of  the  deployment  in  time  units. 

u  is  the  customers  (military  units)  that  require  airlift  support  from  a  particular  on¬ 
load  airfield  to  a  particular  off-load  airfield  (also  called  a  movement  requirement). 

p  is  the  aircraft  types  available  (e.g.C-5,  C-141,  P-747,  etc.).  ^ 

1 

c  is  the  classes  of  cargo  where  c  E  {0  =  outsize,  1  =  bulk,  2  =  passengers } .  The 
class  "oversize”  can  also  be  included  if  desired.  1 

Other  model  parameters  are  explained  following  the  objective  function  or  constraint  equation  whW 
they  are  first  used.  \ 

6.2  MODELING  OBJECTIVE  1 

The  objective  of  the  model  is  to  minimize  the  total  “cost”  of  the  operation  where  the  two  I 

primary  conqronents  of  cost  are  associated  with  shortfall  (undelivered  cargo)  and  use  of  aircraft 
resources.  This  objective  provides  a  flexible  way  of  controlling  the  model  to  minimize  shortfall, 
aircraft  usage,  or  any  suitable  combination. 
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6.2.1  DECISION  VARIABLES 

Values  for  the  following  variables  are  determined  by  tlie  ACER  model: 

^  upcr  ^  numter  of  aircraft  of  type  p  scheduled  to  begin  an  airlift  mission  on 

^y  t  carrying  cargo  of  class  c  from  unit  u  Ml  router.  This  variable  can  also  be 
interpreted  as  the  flow  (movement)  of  preferred  cargo  of  class  c  from  unit  u 
along  route  r  where  amount  of  cargo  moved  is  X  payloads  of  aircraft  type  p. 

^upcr  ^  ^  oppor^e  movement  of  non-preferred  cargo  of  class  c  from  unit  u 
earned  on  aircraft  type  p  along  route  r  beginning  on  day  L 

is  shortfall  -  the  amount  of  cargo  of  class  c  from  unit  u  left  undelivered  at  the 
end  of  the  plaruiing  horizoa 

6.2.2  OBJECTIVE  FUNCTION 

The  objective  function  used  in  the  basic  problem  is  to  minimize  the  “cost”  of  the  airlift.  This 
cost  is  defined  to  be  a  combin^on  of  the  penalty  cost  of  not  delivering  requirements  (shortfalls) 
and  the  cost  of  operating  the  aircraft.  This  objective  function  is  obviously  not  meant  to  be  an 
^^e  indicator  of  the  true  cost  of  the  operatioa  which  would  be  almost  impossible  to  determine 
m  the  early  stages,  but  is  meant  to  combine  the  conflicting  objectives  of  minimizing  shortfall  and  the 
numbCT  of  aircr^  employed  in  a  way  that  will  result  in  a  balanced  airlift  flow.  Mathematically  the 
objective  funedon  is  expressed  as: 


Minimize 


2)  p  Z  + 

UC^uc  uc 


2;._v‘  X‘ 

UCprt  pu  upcr 


(1) 


where,  is  the  penalty  for  shortfalling  one  urut  of  cargo  class  c  of  requirement  u. 

'^'pu  ^  using  aircraft  type  p  to  move  a  requirement  from  unit  u 

during  time  period  L 

By  controlling  the  values  of  p  and  v,  the  objective  function  can  be  formulated  to  minimize 
ei^er  shortfall  (by  setting  all  v  =  1  and  adjusting  p),  aircraft  usage  (by  setting  all  p  =  1  and 
adjusting  v),  or  both  using  a  suitable  combination  of  weights.  The  model  can  be  made  to  deliver 
each  movement  requirement  as  early  as  possible  within  the  pickup  window  by  increasing  v  as  t 
increases. 


6.3  CONSTRAINT  EQUATIONS 

The  coiistrants  used  in  ACEP  can  be  grouped  into  four  categories:  movement  constraints 
aircraft  constraints,  throughput  constraints,  and  enroute  constraints. 

6.3.1  PRIMARY  MOVEMENT  CONSTRAINTS 

.  following  coiBtraints  ensure  that  all  cargo  and  passengers  are  either  delivered  or  reponed 
as  sti^^l  Equation  (2)  represents  outsize  cargo,  equation  (3)  represents  bulk  cargo,  and 
equatiOT  (4)  is  for  passengers,  (hie  set  of  equations  is  necessary  for  each  requirement.  It  is 
assumed  that  no  aircraft  types  have  a  non-preferred  cargo  type  of  “outsize”. 
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^peQo^i€C(p,b)^ieAuip^ip^  upOr  ^  ^uO 


=  q„  (2) 

uO 


2)peQi2j€C(p,b)^tGAu^Y^^*„p,r'^2!peQi2j€C(p,b)^tEAun,'*‘rp''^„pi/^ui"‘^uj 

^p£Q2^r€C(p,b)^tSAu,p^,:p^  up2r  ^  ^pGQ2^l€C^,b)^t^uip^tp^up2r^  ^u2  ~  ^u2 

where;  is  the  amount  (in  tons  or  number  ofpassengers)ofcargo  in  class  c  of 

requirement  u. 

C2.  is  the  set  of  aircraft  types  widi  capability  to  carry  cargo  type  c. 

c 

C(p,b)  is  the  set  of  routes  that  can  be  flown  by  aircraft  type  p  based  at  airfield  b. 

Yjp  isthectqracity  of  aircraft  type  p  on  router  for  its  preferred  cargo  type. 

is  the  capacity  of  aircraft  type  p  on  route  r  for  its  non-preferred  cargo. 

A^,^  is  the  pickup  window  (set  of  feasible  time  units  for  loading  aircraft)  for 
requirement  u  using  aircraft  type  p  on  route  r. 

6.3.2  SECONDARY  MOVEMENT  CONSTRAINTS 

These  constraints  ensure  that  the  opportune  movement  of  cargo  and  passengers  (non-preferred 
types)  is  proportional  to  the  movement  of  preferred  cargo  (one  equation  for  each  route,  aircraft 
t)^,  and  time  unit).  Equation  (5)  represents  bulk  cargo  carried  on  passenger  aircraft  and  equation 
(6)  represents  passengers  catri^  on  cargo  aircraft.  Again,  it  is  assumed  diat  any  non-prefeired 
capacity  will  be  in  cargo  classes  “bulk”  or  “passengers”  only. 

S.y  ,  s2x‘  ^  (5) 

U  uplr  U  up2r 

y,Y*  ^2,.CX*  +x‘  ]  (6) 

"U  up2r  "U*-  uplr  upOf*  '  ' 

6.3.3  AIRCRAFT  CONSTRAINTS 

The  constrmnts  represented  in  equation  (7)  ensure  that  the  number  of  aircraft  used  is  less  than 
or  equal  to  the  number  available  (one  equation  for  each  aircraft  type  p  based  out  of  airfield  b  during 
time  t). 

2uC^l€C(p,b)^*k=(t-apr)^  upcr  ^  *pb 


where:  is  the  length  of  the  round  trip  (cycle  time)  for  aircraft  type  p  on  route  r. 

Note:  must  be  an  integer  value. 
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a  is  the  number  of  aircraft  of  type  p  based  at  airfield  b  on  day  t 

Equation  (8)  ensures  that  the  aircraft  UTE  rates  are  not  exceeded.  One  equation  is  required  for 
each  UTE  period,  aircraft  type,  and  operating  base. 


^l6H^ucr^bGR(b,t-c^- 1 ) 


F 

rbp 


X 


upcr 


£ 


UTE'^  a* 

P  pb 


(8) 


where:  p  is  the  set  of  time  units  (surge  period)  over  which  the  UTE  is  enforced. 
These  will  normally  (1,2,3),  (1, ...,  15),  and  (1, 45). 

R(b,t)  is  the  set  of  airfields  visited  t  time  units  after  the  start  of  route  r. 

is  the  number  of  time  units  required  to  reach  airfield  b  on  route  r. 

F .  is  the  time  required  for  an  aircraft  of  type  p  to  fly  to  the  next  airfield  on 
route  r  after  airfield  b. 

UTE'^p  is  the  objective  UTE  rate  for  aircraft  type  p  over  surge  period  p  (daily 
UTE  rate  adjusted  for  the  time  units  used). 

*  6.3.4  THROUGHPUT  CONSTRAINTS 


The  throughput  constraints  ensure  that  the  airlift  operation  does  not  exceed  the  capabilities  of 
the  aerial  port  units  at  the  on-load  and  off-load  airfields  (one  equation  for  each  on-load  or  off-load 
airfield  and  time  unit).  Equation  (9)  is  for  cargo  (bulk  and  outsize)  throughput  and  (10)  is  for 
passenger  throughput. 

I 


^U3o(u)— b^^pGS2l^rGC(p,b)^rp^  upOr  uplr^  ^pSS22^r€C(p,b)^rp  uplr^ 


t-oirb-1 


'u3d(u)=b‘ 


'pEQi  ^r€C(p,b)''ip 

2ped22r€C(p,b)‘**n.^ 


upOr 


uplr 


)  + 


S 


bl 


(9) 


^u30(u)=b^^pe£22^r€C(p,b)^tp^up2r  ^^p££2l^l€C(p,b)*^rp^up2f^  ^ 


'peQ2^r€C(p,b)V'"‘''^'up2r'^  ^p€Ql^l€C(p,b)‘*'rp^'^’^’upJ 


where:  6*^,  is  the  throughput  capacity  of  airfield  b  at  time  t  for  cargo  class  c'  where 

c’  €  { 1  =  cargo,  2  =  passengers). 


o(u)  is  the  on-load  airfield  for  requirement  u. 


d(u)  is  the  off-load  airfield  for  requirement  u. 
6.3.5  ENROUTE  CONSTRAINTS 


The  enroute  constraints  ensure  that  the  capacity  of  the  enroute  airfields  to  support  the  airlift 
(MOG)  is  not  exceeded  (one  equation  for  each  enroute  airfield  and  time  unit). 
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(11) 


V  V  _  vt-^lrb-l 

‘^ucp^i€C(p,b)nR(b,t-atb-l)  bp  upo- 


^  inin(e*, W*  ) 

b  b 


where:  m  is  the  amount  of  MOG  (parking  or  working  -  depending  on  which  is 
most  limiting  at  the  airfield)  used  by  aircraft  type  p  at  airfield  b. 


e\  is  the  ramp  cqracity  (parking  MOG)  of  airfield  bat  time  L 


w^^  is  die  working  MOG  of  airfield  bat  time  L 

6.4  DELIVERED  CARGO-TO-PASSENGER  RATIO 

EBstorically,  one  ton  ofcargo  must  be  delivered  for  each  passenger.  This  constraint  ensures 
that  the  correct  proportion  of  cargo  to  passengers  is  delivered  over  the  planning  period.  Since  the  1 
to  1  ratio  is  not  always  qipropriate,  the  ratio  can  be  adjusted  to  meet  planning  needs. 

WU*  Vfv*  J  *  p  <>'> 

where:  fi  is  the  desired  ratio  ofcargo  to  passengers  delivered. 

6.5  MINIMUM  LOAD 

All  the  decision  variables  are  defined  to  be  non-negative.  A  minimum  load  to  justify 
scheduling  a  mission  by  a  particular  aircraft  type  may  be  enforced  as  follows: 

X*  2  (13) 

upcr  upcr  pc  ^ 

where:  is  f  1  if  is  greater  than  zero 

k  0  otherwise 

minload  is  the  minimum  load  desired  as  a  percentage  of  capacity. 

Note,  however,  that  this  constraint  requires  a  reformulation  of  the  objective  function  to  include  the 
0-1  variables  and  results  in  a  mixed-integer  programming  problem  of  very  large  size. 

7.0  MODEL  OUTPUT 

The  ouqiut  from  the  model  will  consist  of  a  printed  solution  identifying  the  optimal  value 
found  for  the  otgective  function  and  decision  variables  as  well  as  sensitivity  analysis  information 
associated  with  each  variable  and  constraint 

7.1  DECISION  VARIABLES 

The  model  will  report  optimal  values  of  two  primary  decision  variable  types.  First  the 
shortfall  for  each  unit  and  cargo  class  will  be  reported.  Second,  a  flow  variable  for  each  aircraft 
type,  cargo  type,  and  time  period  will  be  report^.  This  flow  variable  may  be  interpreted  as  the 
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number  of  swties  scheduled  by  the  model  to  start  in  each  time  period.  This  variable  will  NOT  be 
integer  in  most  cases. 

7.2  SENSITIVITY  INFORMATION 

The  standard  solution  sensitivity  information  provided  by  linear  program  solvers  will  be 
available  including; 

(1)  die  reduced  cost  fw  each  non-basic  decision  variable  (the  expected  improvement  in  the 
objective  function  coefficient  associated  with  the  variable  that  must  be  made  in  order  for 
the  solution  to  include  the  variable  at  a  non-zero  level).  This  information  can  be  used  to 
determine  the  amount  by  which  the  cost  of  using  a  particular  aircraft  type  must  improve  in 
order  to  use  that  type  during  a  time  period  wl^n  it  is  not  currently  included  in  the  optimal 
solution. 

(2)  the  shadow  price  for  each  constraint  (the  expected  improvement  in  the  objective  function 
given  by  a  unit  increase  in  availability  of  the  resource  being  constrained).  This 
information  can  be  used  to  determine  which  of  the  constrained  resources  (aircraft  and 
airftelds)  is  most  critical  and  should  be  the  focus  of  any  effort  to  add  resources  to  improve 
the  airlift  flow. 

The  sensitivity  information  outlined  above  is  unique  for  the  particular  optima]  solution  found 
by  the  solver.  If  the  solution  (optimal  basis)  changes,  then  the  sensitivity  information  must  be 
recomputed. 
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8.0  VERinCATION  OF  DESIGN 


Table  21  shows  a  trace  of  the  model  requirements  to  the  mathematical  equation  in  the 
formulation  where  the  requirement  is  satisfied: 

TABLE  21 

Requiiements  Verification  MMiix 


Model  Equation  that  Satisfies  Requirement 


11 


equirement 


Sectional 

MinhnireShortfill 


Section  SI 
Planninp  HorizDa 


Section  52 
Deliver  Outsize 
DdiverBUlk 
Deliver  Passengers 
Uk  Delivery  Window 
Csrgo/Ressenger  Rstio 


Section  S3 
Aviilable  Routes 


Section  S4 

Gugo  Throu^iput  Limits 
Rusenger  Throughput  Limits 
MOG  Limits 


Section  SS 
AiicaftCkpaci^ 
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Appendix  C:  GAMS  Implemeniation  of  ACER 
with  Ctmtrived  Scenario 


*1^1^■^^■^^**^l1Hi*ilf^*^i^^*■^t*^^^^t^:^^H^^,**:^L^|L*i|^i^^L^^^i***********^^***************** 

*  Filename:  ACEP.gms  * 

*  * 

* 
♦ 
* 


*  Purpose: 

* 

* 


VerificadonA^alidation  of  Airlift  Capability 
Estimation  Prototype  (ACEP)  Model. 


ti****:^******^!**************************************************** 

$OFFSYMXREF 

SOFFSYMUST 

$OFFUPPER 

OPTIONS  ITERLIM=5000,LIMCOL=0.LIMROW=0 ; 

OPTION  SOLPRINT=OFF ; 

*  time  =  set  of  time  units  in  model  planning  period  * 

*  * 

set  should  cover  COl  to  end  of  desired  horizon  * 

plus  enough  time  units  to  cover  the  longest  route  * 

cycle.  Tltis  prevents  the  model  fi’om  over-  * 

scheduling  at  the  end. 


•  NOTE: 

* 

4> 

* 


SET  time  Time  periods  in  the  model 
/C01*C64/ 

alias(time,time2) ; 

^t*********************************************************** 

*  TUNTT  =  time  units  per  24  hour  period  (e.g.  TUNTT  =  2  * 

*  means  that  TAfl  =  12  hour  time  periods  are  used)  * 

SCALAR  TUNTTS/ 2/;  , 


ctctlic^li^ctc^ilc^ctc^^^^ccIc^itc^^^^lcitccIccIc^^ili^c^^e^i^ctcitictc^c^^cfcOXcilKi^^IrctcOcctc^^oIcctc^cfi^cctc** 


*  unit  = 

* 


designator  for  the  military  units  (hirlift 
customers)  that  require  transport], 


* 

* 


I|>4>4c4i4>*4>il>i|c4c4i4t4c4is|t4c4c4i4i!tc4i4c4c4c4>4i4>4<4<4<4'4<4>4<4i4>4c4c4c4c4(i|c4c4c4c4i4i4i4t4t4i4ei(c4i4ti(i]tc4ci|citc4i 

\ 

SET  unit  Unit  requiring  movement  of  car^o  or  pax 
/U01*U04/; 


4i*4t4t*4c4>4i4>4i*4i4>4c!t>4c4»lc4>4<4'4>4<it>4i4c4c4i4c4t4c4c4c4t4c]|i4>4>4<:|c4i4i4ci^4c4c4c4i4c4c4c4c4c4c4c4c4c4c4c4c4c 

•  plane  =  set  of  aircraft  resources  available  fw  use  at  * 

*  any  time  during  the  airlift  operation.  * 

4i4t4i4ci|i4i4c4i4i4c4c4i4i4cc#4c4<4<4c4i3|ci|t4citc4c4<4<4i4c!|citc4c4is|c4ci|c4c4>4<4t4>4<4c4>4'4'*4c4i4c4:4'4'4c!tc4i4i4i4'4>4> 
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SET  plane  Types  of  aircraft  available 

/C141,C005,C017,P747/ 

*  class  =  set  ofcargo  classes  (usually  the  airlift  * 

*  requirements  can  be  classified  into  AT  MOST  four  * 

♦  classes:  outsize,  oversize,  bulk  and  passengers)  * 

SET  class  Types  of  cargo  or  pax 

/out,blk,pax/; 

♦  cargo  =  set  of  classes  that  include  only  true  cargo.  * 


SET  cargo(class)  Types  of  cargo  only 
/out,blk/; 

*it*ii**iit***************************************************** 

*  base=  set  of  airfields  available  for  use  at  any  time  * 

•  during  the  airUft  operation.  The  use  of  the  * 

♦  four  letter  ICAO  designator  works  well.  * 

*04i^t******************************************************** 


SET  base  Airfields  included  in  the  model 

/K001*K006/; 


*  route  =  set  of  routes  available  for  moving  cargo/pax. 

*  A  typical  route  might  be: 

*  STOP  PURPOSE 

*  1  Aircraft  home  (operating)  base 

*  2  On-load  airfield 

*  3  Enroute  airfield(s) 

*  4  Off-load  airfield 

*  5  Recovery  airfield  (refuel,mx) 

*  6  Enroute  airfield(s) 

*  7  Aircraft  home  base 


* 

* 

* 

* 

* 

* 

* 

* 

* 

* 


SET  route  Routes  by  which  cargo  can  move 
/R001*R003/; 

****4i**«**i|i4t*4i***4i4t*:|i:(tl|<«*4i**4ti|i4i,|r««*^**4it*4<**:<i*«****«**4<***!|>** 

*  vtinc=  set  of  time  units  for  referencing  days  within  * 

*  each  aircraft  mission.  Set  should  be  sequential  * 

*  fix)m  0  to  number  of  time  units  in  the  longest  * 

*  roundtrip  cycle.  * 
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SET  vtinc  Time  units  in  the  longest  cycle 
/0*3/; 

***4c!t>:tE:|c:|r:|i:|t*«4>************«*i|<**:)>«**:t>**4>:|^*4<****iti*4'***4>4>4>***4>4>4>* 

*  delta  =  defines  the  pickup  window  for  each  requirement.  * 

*  Delta  is  indexed  by  route  and  aircraft  type  to  * 

*  provide  further  flexibility  in  controlling  the  * 

*  scheduling  of  missions.  Note  that  MANY  of  the  * 

*  constraints  equations  are  $  controlled  with  the  * 

*  delta  set -so  tighter  and  more  specific  delta  * 

*  windows  should  speed  up  the  solve  time,  * 

t******************!tt******:^iii*iHH,it**ili****>HHi}li***1H>*mi******rt‘^* 

SET  delta(unit^oute, plane, time)  Feasible  pick-up  times 

/U01.R001.(C005,C141).(C01  *C60) 

U01.R002.C017.(C01  *C60) 

U01.R002.C141.(C05  *  C60) 

U01.R003.P747.(C05  *  C60) 

U02.R001.(C005,C141).(C15  *  C60) 

U02.R002,(C141,C017).(C15  *C60) 

U02.R003.P747.(C15  *  C60) 

U03.R001.(C005,C141).(C29  *  C60) 

U03.R002.(C141,C017).(C29  *  C60) 

U03.R003.P747.(C29  *  C60) 

U04.R001.C141.(C01  *C60) 

U04.R002.(C141,C017).(C01  *C60)/; 

*  home=  defines  the  home  (operating)  bases  for  the  * 

*  aircraft  for  enforcing  UTE  rates  by  base.  * 


SET  home(base, plane)  Home  base  of  aircraft 

/K001.(C005,C141) 

K002.(C017,C141) 

K003.P747/; 

♦  ♦♦********!)t***********!|C**********************#********  +  ****!(l 

*  head=  the  starting  airfield  on  each  route.  * 

^1i1,t*****************************^t1,ll,ii*ilt*^i4ii)iili^i1i^****iij^******:tt* 


SET  head(base,route)  Starting  point  of  routes 

/K001.R001 
K002.R002 
K003.R003/; 

*  AMOUNT  =  the  amount  of  cargo  (tons)  or  passengers  from  * 

*  unit  that  must  be  moved.  * 
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TABLE  AMOUNT(unit,class)  Amounts  to  be  moved 


out 

blk 

pax 

UOl 

740 

980 

6000 

U02 

440 

680 

7000 

U03 

190 

1040 

1800 

U04 

880 

7700  ; 

iiL*ii!m,^iit***^,*^iHi******************tt**************************)ii 

*  TCLASS  =  total  amount  to  be  moved  in  each  class.  ♦ 

*4i4i:^4i4i***:|t4i*4i*:|r***:|i*:|c*4t*****:ti***3|<4i*iti*!t>4t***4f4'*4»tii|>*«****4>***i|>** 


PARAMETER  TCLASS(class); 

TCLASS(class)  =  SUM(unit,  AMOUNT(unit,class)); 
DISPLAY  TCLASS; 


•  RATIO  =  the  desired  ratio  ofcargo  to  passengers  delivered.  * 

*  Historically,  the  ratio  is  often  near  1.0.  *' 

niiH,i,*^i^i^i*:t‘*************************************************** 


SCALAR  RATIO/0.90/; 

*  flytime  =  flying  time  ^  hours)  accumulated  in  each  * 

*  time  period  (vtinc)  on  each  route.  Note  that  * 

*  aitcr^  are  assumed  to  start  their  missions  * 

*  at  the  beginning  of  vtinc  0.  * 

ti0t*tn,**1iili*****i,iiin,**in,l,in„n,:i,i,***i,t************************** 


PARAMETER  flytime(route, vtinc)  Flight  time  between  stops 

/ROOLO  6,R001.1  8,R001.2  9,R001.3  6 
R002.0  8,  K002.1  7,  R002.2  8,  R002.3  9 
R003.0  10,  R003.1  5,  R003.2  10,  R003.3  3  / ; 

IHtjUit******************************************************** 

*  legtime  =  time  units  on  each  route  (vtinc)  when  the  * 

*  aircraft  will  be  located  at  each  airfield  on  * 

*  the  route.  * 


SET  legtime(route,base,vtinc)  Hme  periods  at  intermediate  stops 

/  R001.(K001,K003,K004).0 
R001.(K004,K005).l 
R001.(K006).2 
R001.(K004,K001).3 
R002.(K002,K003).0 
R002.(K004,K005).l 
R002.(K006).2 
R002.(K004,K002).3 
R003.(K003,K004).0 
R003.(K005,K006).l 
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R003.(K004).2 
R003.(K003).3  /; 

*  onload  =  the  onload  airfield  for  each  requirement  unit  * 


SET  onload(unit, base)  Onload  point  for  each  unit 

/  (U01,U02,U03,U04).K003  / ; 

*  ofQoad=  the  offload  airfield  for  each  requirement  unit  * 


SET  offload(unit,base)  Offload  point  for  each  unit 

/  (U01.U02,U03,U04).K005  / ; 

^i***!li********:Hi*ii**m^iii*^ii,!ti*i:*t,ili****ii**^**^i*t***************** 

*  numplane  =  the  number  of  each  type  of  aircraft  at  each  * 

*  q>erating  base  available  for  use  during  each  * 

*  time  perio  \  * 


PARAMETER  numplanefplane, base, time)  Number  of  aircraft  available 
/C141.K001.(C01*C64)  10 

C141.K002.(C01*C64)  5 

C005.K001.(C01*C14)  10 

C005.K001,(C15*C64)  8 

C017.K002.(C01*C64)  7 

P747.K003.(C05*C64)  3  /; 


*1,^i*1,1t*1,^,*#ili1i1i:H,ii*^i1H,JH,************************************** 

*  period  =  the  UTE  periods  to  be  tracked  in  the  model.  * 

*^ll*ltl***^lt*******************************************■^‘******** 


SET  period  UTE  Periods  tracked  by  model 
/  FIRST,  SECOND,  THIRD  / ; 

*  UTEPRD  =  definition  of  the  UTE  period  (time  units  * 

*  covered).  * 

t********1i******0*****1ii  ♦♦**♦♦****♦***************♦*♦******+* 

SET  UTEPRD(period,time)  Time  periods  covered  by  UTE  periods 

/FIRST.(C01  *C06) 

SECOND.(C01  *C30) 

THIRD.(C01  *C64)/; 

*  UTENUM  =  number  of  time  units  in  each  UTE  period.  * 
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PARAMETER  UTENUM(^ri(xi)  Number  of  Time  Units  in  each  UTE  Period 

/FIRST  6 
SECOND  30 
THIRD  64  /; 

UTERATE  =  the  DAILY  UTE  rate  for  each  aircraft  type  (in  ♦ 

*  h(Hirs  of  fliglit  time  per  day).  * 

************************************************************* 

TABLE  UTERATE(period,plane)  Daily  UTE  rates  for  aircraft 


C141 

COOS 

C017 

P747 

FIRST  4 

4 

4 

SECOND  13 

12 

■  14 

10 

THIRD  12 

10 

12 

10 

************************************************************* 

*  UTEHOURS=  the  total  pool  of  flying  hours  available  for  * 

*  each  UTE  period,  aircraft  type  and  operating  * 

*  base  (computed  automatically).  ♦ 

**********************!>************************************** 


PARAMETER  UTCHOURS(petiod,base, plane); 

UTEHOURS(period,baM,plane)$HOME(base, plane)  = 
SUM(time$(UTEPRD(period,time)$NUMPLANE(plane,base,time)), 
NUMPLANE(plane, base, time)  •  (UTERATE(period,plane)/TUNITS) ); 

************************************************************* 

*  CYCLE  =  the  number  of  time  units  required  to  complete  * 

♦  each  route  by  each  type  of  aircraft.  * 

************************************************************* 


TABLE  CYCLE(route, plane)  Length  of  'oundtrip  cycle 
C141  COOS  C017  P747 

ROOl  i  4  4  4  4 

R002  14  4  4  4 

R003  14  44  4 


**********41************************************************** 

*  PARK=  1  the  number  of  aircraft  parking  spots  available  * 

*  lot  each  airfield  and  unit  of  time.  NOTE:  the  * 

*  time  inctex  is  included  to  account  for  other  * 

*  Wlift  traffic  that  may  effect  ramp  space  * 

*  avaUable  at  various  times.  • 

************i|i************************************************ 

] 


PARAMETER  PARK(base,time) 

Parking  MOG  limits  at  each  base 

/K001.(C01*C64) 

25 

K002.(C01*C64) 

75 

K003.(C01-K:64) 

15 

K004.(C01*C10) 

30 
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K004.(C11*C64)  40 

K005.(C01*C64)  25 

K006.(C01*C64)  20  /; 

•  WORK  =  the  working  MOG  limits  at  each  airfield  and  time.  * 

♦  Working  MOG  includes  such  factors  as  refueling  * 

*  capability  and  operating  hours.  * 

**:Ht*Jti*i)t***************************************************** 


PARAMETER  WORK(base,time) 
/K001.(C01*C64)  50 

K002.(C01*C64)  25 

K003.(C01*C64)  20 

K004.(C01*C64)  25 

K005.(C01*C64)  50 

K006.(C01*C04)  20 

K006.(C05*C20)  10 

K006.(C21*C64)  20  /; 


Working  MOG  limits  at  each  base 


************************************************************* 

*  AMOG  =  the  most  constraining  (i.e.  minimum)  MOG  at  each  * 

*  airfield  and  time.  * 

*****************************************************ti  ******* 

PARAMETER  AMOG(base,lime): 

AMOG(base,time)  =  MIN(FARK(base,time),WORK(base,time)); 

*  MOG  =  the  amount  of  parking  and  working  MOG  that  each  * 

*  type  of  aircraft  uses  at  each  airfield.  * 

*  Note:  largeraircraft  will  use  a  proportionally  * 

*  higher  amount  of  MOG.  The  airfield  index  is  * 

*  included  to  provide  further  flexibility.  • 


TABLE  MOG(base,plane)  MOG  used  by  each  aircraft  type  at  each  base 


C141 

C005 

C017 

P747 

KOOl 

1 

2 

1.2 

2.1 

K002 

1 

2 

1.2 

2.1 

K003 

1 

2 

1.2 

2.1 

K004 

1 

2 

1.2 

2.1 

K005 

1 

2 

1.2 

2.1 

K006 

1 

2 

1.2 

2.1  ; 

**************************il,****^i^*il,iti***ll,il,iHk*^ili!>,il,^,il,i,1,7l,*:),i,**:ti*^i 

*  THRU  =  the  cargo  and  passenger  throughput  limitations  at  * 

*  the  onload  and  offload  airfields  (expressed  in  * 

*  tons  of  cargo  or  number  of  passengers  per  time  * 

*  unit).  * 
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PARAMETER  THRU(base, time, class)  Throughput  limits  at  onload  &  offload 
/K003.(C01*C64).pax  2500 
K003.(C01*C05).blk  120 

K003.(C06*C64).blk  180 

K005.(C01*C08).pax  1000 

K005.(C09*C64).pax  3000 
K005.(C01*C64).blk  300  /; 

t******************0*********>li*ili**m*lli*1i**ilt:^*^i**************** 

*  RHO=  the  penalty  associated  with  failing  to  deliver  one  * 

*  ton  ofcargo  or  one  passenger  from  each  unit.  * 

*  Note  that  unit  priwities  can  be  handled  by  * 

*  adjusting  dlls  parameter.  Also,  RHO  should  be  set 

*  greater  Aan  or  equal  to  the  highest  penalty  for  ♦ 

*  each  sortie  (see  NU).  * 


TABLE  RHO(unit,class)  Penalty  for  shortfall 


out 

blk 

pax 

UOl 

100 

lOO 

100 

U02 

100 

100 

100 

U03 

100 

100 

100 

U04 

100 

100 

100  ; 

*****************************************i,****************** 

NU  =  the  penalty  associated  with  using  each  aircraft 

type  to  deliver  cargo^ax  from  each  unit.  Note:  * 

the  use  of  a  particular  type  of  aircraft  can  be  ♦ 

controlled  (minimized  or  maximized)  by  setting  the  ♦ 

penalty  appropriately  hign  or  low  in  relation  to  ♦ 

Jie  other  aircraft  penalties.  * 

************************************************************ 


TABLE  NU(unit,plane)  Penalty  for  each  sortie  flown 


C141  C005  C017 

UOl  1  1  1 

U02  1  1  1 

U03  1  1  1 

U04  1  1  1 


P747 

2 

2 

2 

2  ; 


*******************************,■***************************** 

*  NUNU  =  the  aircraft  use  penalty  adjusted  to  iiKrease  * 

*  with  time.  This  forces  the  model  to  move  the  ♦ 

*  cargo/pax  as  soon  as  possible  (maximizes  flow  * 

*  until  all  requirements  are  delivered).  * 

*********************4-*************************************** 


PARAMETER  NUNU(unit,plane,time); 

NUNU(unit,plane,time)  =  NU(unit,plane)  +  ORD(time) ; 
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*  PREFER  =  the  cargo  or  passenger  capacity  for  each  * 

*  aircraft  type  for  it's  preferred  cargo  (in  tons  "■ 

*  or  number  of  passengers).  "■ 


PARAMETER  PREFER(plane, class  joute)  Cr^acities  for  preferred  cargo 
/C141.blk.(R001,R002)  19 

C141.pax.(R001,R002)  130 


C005.(out,blk).R001  60 

C017.out.R002  38 

C017.blk.R002  40 

P747.pax.R003  365  /; 


*  NONPREF  =  the  cargo  or  passenger  capacity  for  each  "■ 

*■  aircraft  type  for  it's  non-preferred  cargo  On  * 

*  tons  or  number  of  passengers).  * 

j 

PARAMETER  NONPREF(plane, class  joute)  Capacities  for  nonpreferred  cargo 
/C005.pax.R001  68/; 


FREE  VARIABLES 

COBJ 

DOBJ 

•  I 

rosmVE  VARIABLES 
X(time,unit,plane,class,route) 
Y(time,unit,plane,classjoute) 
Z(unit,class)  | 


EQUATIONS  I 

COST 

DELIVER 

DELIVPAX(unit) 

DELrVBLK(unit) 

DELIVOUT(unit) 

NONPREFl(route, plane, time) 

NONPREF2(route,plane,time) 

AVAILftrlane, base, time) 

THRUPUTl(base,time) 

THRUPUT2(base,time) 

MOGLIM(base,time) 

UTELIM(period,base,plane) 

DELRATO 


Cost  of  operation 

Amount  of  tons  &  pax  delivered 


Number  of  sorties 

Opportune  movement  of  nonprefened  cargo 
Amount  left  undelivered  (shcntfall) 


Objective  "cost"  function 

Oyective  flow  function 

Account  for  passenger  requirements 

Account  for  bulk  cargo  requirements 

Account  for  outsize  cargo  requirements 

Opportune  cargo  on  pax  planes 

C^portune  pax  on  cargo  planes 

Number  of  aircraft  available 

Cargo  throughput  at  onload  &  offload  airfields 

Pax  throughput  at  onload  &  offload  airfields 

MOG  limits  at  enroute  airfields 

Aircraft  utilization  constraints 

Ratio  of  delivered  cargo  to  pax 
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COST..  COBJ  =E=  SUM((unit,class)$AMOUNT(unit,class),  RHO(unit,class)  * 
Z(uriit, class))  +  SUM((unit,class4t)ute, plane, time) 
$((lelta(unit4X)ute,plane,tinie)$PREFER(plane,class,route)), 
NUNU(unit,plane,time)  *  X(time,umt,plane,class,route) ) ; 

DELIVER..  DOBJ  =E=  SUM((time,unit,plane,class,route) 
$delta(umt,route,plane,time), 

PREFER(plane,class,route)  ♦  X(time,iinit,plane,class,route) 

+  NONPP.EF(plane,class/oute)  ♦  Y(time, unit, plane, class,route) ) ; 

DELIVPAX(unit)$AMOUNT(unit,"pax")..  AMOUNT(umt,'’pax")  =E=  Z(unit,"pax") 
+  SlJM((route,plane,time)$delta(unit4'0ute,plaue,time), 
PREFER(pIane,"pax",route)  *  X(tinie,unit,plane,"pax'*,route) 

+  NONP^F(plane,"pax",route)  ♦  Y(time,unit,plane,"paxVoute) ) ; 

DELIVBLK(unit)$AMOUNT(uiat,"blk")..  AMOlINT(unit,"blk")  =E=  Z(unit,'*blk") 
■f  SUM((route,plane,time)$deIta(unit,route,plane,time), 
PREFER(plane,"blkVoute)  *  X(time,unit,plane,*'blk",route) 

+  NONPl^F(piane,"blk",route)  •  Y(time,urat,piane,"blk",route) ) ; 

DEUVOUT(unit)$AMOUNT(unit,'’out")..  AMOUNT(unit,"cuf')  =E=  Z(uniu”out") 
+  SUM((route,plane,time)$(ielta(uniuoute,plane,timc), 
PREFER(plane,"out",route)  *  X(time,unit,plane,"out",route) ) ; 

NONPREFl(route,plane,time)$NONPREF(p!ane,”blkVoute).. 
SUM(unit$deIta(unit,rcute,plane,time), 
X(time,unit,plane,"pax",route)$PREFER(planc,"pax"jrDute) 

-  Y(time,unit,plane,"bIk",route)$NONPREF(plane,"bIkVoute) )  =G=  0.0; 

NONPREF2(route,plane,time)$NONPREF0)lane,"pax"/oute).. 
SUM(unit$delta(unit4'oute,plane,time). 
X(time,unit,plane,"out"/oute)$PREFER(plane,"out",route) 

+  X(time,uait,plane,"Uk"/oute)$PREFER(plane,"blk",route  ) 

-  Y(time,unit,plane,"pax"4'Oute)$NONPREF(plane,"paxVoute) )  =G=  0.0; 

AVAIL(plane,base,time)$NUMPLANE(plane,base,time).. 
NUMPLAN^lane,base,time)  =G=  SUM((route,time2) 

$((ORD(time2)  le  ORD(time))  ami  (ORD(time2)  gt  (ORD(time) 

-  CYCLE(route,plane)))$head(base,route)), 
SUM((unit,class)$(delta(unit40ute,plane,time2) 

$PREFER^lane,class,route)),  X(time2,unit,plane,class4'oute) ) ) ; 

THRUPUTl(base,tiine)$THRU(base,time,"blk")..  THRU(base,time,"blk")  =G= 
SUM(un>t$onload(unit,base), 

SUM((route,plane)$delta(unit,route,plane,time), 

PREFER(plane,"blk",route)  *  X(time,unit,plane,"blk"jroute)  + 
PREFER^lane,"out"4'oute)  *  X(time,unit,plane,"out",route)  + 
NONPREF(plane,"blk"4-oute)  *  Y(time,unit,plane,"blk",route) ) )  + 

SlJM(unit$ofaoad(unit,base), 
SUM((route,plane,vtinc)$(legtime(route,base,vtinc) 
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$delta(unit^ute,plane,time-(ORD(vtinc>-l))), 

PREFER(plane,"blkVoute)  * 

X(time-(ORD(vtinc)- 1  ),unit,plane,''blk"/oute)  + 
P]^FER(plane,"out"/oute)  * 

X(time-(ORD(vtinc)- 1  ),unit,plane,"out"4-oute)  ^ 
NONPREF(plane;’blkVoate)  * 
Y(tinie-(ORD(vtinc)-lXunit,plane,"blk";route) ) ) ; 

THRlJPUT2(base,time)$THRU(base,time,"pax")..  THRU(base, time, "pax")  =G= 
SUM(umt$onload(unit,base), 
SUM((route.plane)$delta(unitj-oute.plane,time), 
PREraR(j)lane,"pax",route)  *  X(time,unit,plane,"pax", route) + 
NONPRCT(plane,"pax",route)  *  Y(time, unit, plane, "pax",route) ) )  + 

SlTM(unit$offIoad(unit,base), 

SUM((route,plane,vtinc)$(legtime(route,base,vtinc) 

$delta(unit,route,pIane,time-(ORD(vtinc)kl))), 

PREFER(plane,"pax",route)  * 

X(time-(ORD(vtinc>  1  ),unit,plane,"pax",route)  + 
NONPREF(plane,"pax",route)  * 
Y(ti»ne-(ORD(vtinc)-l),unit,plane,"pax"/oute) ) ) ; 

MOGU  \base,time)$AMOG(base,time)..  AMOG(base,time)  =<J= 
SLiM((unit,class,route,plane,vtinc)$(legtime(route,base,vtinc) 
$(delt^unit/oute,plane,time-(ORD(vtinc>l )) 

$PREFER(plav  e,class,route))), 

MC)G(base,plane)  *  X(time-(ORD(vtinc>l),unit,plane,classjoute) ) ; 

UTELIM^eriod,base,plane)$HOME(base,plane).. 

UTEHOURS(period,base,plane)  =G=  SUM(tirae$UTEPRD(period,time), 
SUM((unit,classjoute,vtinc)$(n.YnME(route,vtinc) 
$(DELTA(unitJoute,pIane,time-(ORD(vtinc)- 1 )) 
$(PREFER(plane,classjoute)$IffiAD(basejoute)))), 

FLYTIME(route,vtinc)  *  X(time-(ORD(vtinc)-l),unit,plane,class,route))); 

DELRATO..  SUM((tinie,unit,plane,class,route) 

$(DELTA(unit,route,plane,time)$(AMOUNT(unit,class)$cargo(class))), 
PREFER(pIane,class,route)  *  X(tirae,unit,plane,class,route)  + 
riONPREF(plane,class,route)  *  Y(time,unit,plane,class,route) ) 

-  RATIO  *  SUM((time,unit,plane,route)$DELTA(unit4'oute,pIane,time), 
PREFER(plane,"pax"4-oute)  *  X(time,unit,plane,"pax"4-oute)  + 
NONPREF(planfc,  "pax", route)  *  Y(time,unit,plane,"pax"4-outp) )  =G=  0.0 ; 

MODEL  ACEPC  /  COST,  DELIVPAX,  DEUVBLK,  DELIVOUT, 

NONPREFl,  NONPREF2,  MOGLIM,  THRUPUTl, 
THRUPUT2,  AVAIL,  UTELIM,  DELRATO  / ; 

MODEL  ACEPD  /  DELIVER,  NONPREFl,  NONPREF2,  AVAIL, 

MOGLIM,  UTELIM,  THRUPUTl,  THRUPUT2, 
DELRATO/; 
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4i*i|i**4i*4i«**4t4i*****4<*4i**4t4i*4i«**4i4t*«*4i**4i!|i4i4t***:»4>*«***>t<4>«*4>:|<*** 

*  Solve  model  ACEPC  (minimize  "cost")...  * 

t^4i****************#****1t*^^*******************‘*************** 

SOLVE  ACEPC  USING  LP  MINIMIZING  COB  J ; 

*  Compute  max  percent  of  available  aircraft  used  and  the  * 

*  marginal  value  for  maxed  aircraft..  * 

^^^Hiilfili^i^^i^t^,^,itj^^iilii)i^ii,i^^*jt‘********lt****************************** 


PARAhffiTER  PAVAIL(plane,base)  Max  Percent  of  Available  ACFT  Used; 
PA  VAIL^lane,base) = 0; 

PARAMETER  AAVAIL^)eriod,base,  plane)  Average  Number  ACFT  Used; 
AAVAIL(period,base,  plane)  =  SUM(day$UTEDAYS(period,day), 
-AVAIL.L(plane,base,^y)  /  UTENUM(period) ; 

PARAMETER  MAVAIL(plane,base)  Marginal  Value  of  Aircraft; 

MAVAIL^lane,base) = 0; 

LOOP(time, 

PAVAtt.(plane,base)$NUMPLANE(pIane, base, time)  = 

MAX(  PAVAIL(^lane,base),  (-AVAIL.L(plane,base,time)  / 
NUMPLANE(plane, base, time)) ) ; 
MAVAIL(plane,base)$NUMPLANE(pIane,base,time)  = 
MAVAIL(piane,base)+  AVAILM^lane,base,time) ); 

DISPLAY  PAVAnU 
DISPLAY  AAV  AIL; 

DISPLAY  MAV  AIL; 

*  Conqrute  max  cargo  throu^put  at  each  base  onload  and 

*  ofQo^  airfield  (percent  ofcapacity)  and  the  marginal  * 

*  value  for  the  maxed  out  airfields...  • 

4i4i**4i*4c*4i4ii|i4i4i3|tv  4c4r4r:fi*4i*4i4f4i4i«4r4t4r4c:)i4c:|c:tt4r:|i*%:(c^^:|i4t4i4i:t>:<iit>1>*4i4i4>***4i4i4i<tii|< 

I 

PARAMETER  PCTHRU(base)  Max  percent  of  cargo  thruput  used; 
PCTHRU(base)  =  0;  1 

PARAMETER  MCTHRU(base)  Marginal  Value  of  Base  (Cargo); 

MCTHRU(base)  =  0;  i 

LOOP(time,  \ 

PCTHRU(base)$THRU(base,time,"bIk")  = 

MAX(  PCTHRU(base),  (-f^UPUTl.L(base,time)/ 
THRU(base,time,"blk")) ); 
MCTHRU(base)$THRU(base,tiine,"bIk")  = 

MCTHRU(base)  +  THRUPl}m.M(base,time) ); 

DISPLAY  PCTHRU; 

DISPLAY  MCTHRU; 


*  Compute  max  passenger  throughput  at  each  base  onload  * 

*  and  offload  airfield  and  marginal  value  for  the  maxed  * 

*  airfields...  * 

t******************’’:***************************************** 


PARAMETER  PPTHRU(base)  Max  percent  of  PAX  thruput  used; 
PPTHRU(base)  =  0; 

PARAMETER  MPTHRU(base)  Marginal  Value  of  Base  (PAX); 

MPTHRU(base)  =  0; 

LOOPCtime, 

PPTHRU(base)$THRU(base,time,"pax")  = 

MAX(  PPTHRU(base),  (-THRUPUT2.L(base,time)/ 

THRU(base, time, "pax")) ); 
MPTHRU(base)$THRU(base,time,"pax")  = 

MPTHRU(base)  +  THRUPUl  •.M(base,time) ); 

DISPLAY  PPTHRU; 

DISPLAY  MPTilRU; 

*  Compute  max  MOG  used  at  each  base  and  the  marginal  * 

*  value  for  the  airfields  where  ramp  space  is  used  up...  * 

*i|i!ti*4i**4>**4<*«*->*«4>4<«*4<i>4<«4>4>3<<4«'**«!ft«****4t*4>*>l<*4>********«*****4i 

I 

! 

PARAMETER  PMOG(base)  Max  percent  of  MOG  used;  | 

PMOG(base)  =  0;  ! 

PARAMETER  MMOG(base)  Marginal  Value  of  Base  (MOG); 

MMOG(base)  =  0; 

LOOP(time,  | 

PMOG(base)$AMOG(base,time)  = 

MAX(  PMOG(base),  (-MOGLIM.L(base,time)  /  AMOG(base,time)) ); 
MMOG(bffie)$AMOG(base,time)  = 

MMOG(base)  +  MOGljM.M(base,time) ); 

DISPLAY  PMOG; 

DISPLAY  MMOG; 

*  Conqrute  total  amount  of  cargo  and  pax  scheduled  for  * 

*  delivery...  * 

**i|ti|ci|i4i]|ii|c4i4ci|c4ci|c4c4c4c’|ci|ci|i4c4i4ii|c*4'i|<**4ii|i4ii|i4i4c4ii|c4ii|i]|fi|c*4cc|i4i4c4c4c4ci|i4ii|ii|>i|ii|i4i4ci|ci|c4c4c4i 


PARAMETER  TOTAMT(class); 

TOTAMT(class)  =  SUMfunit,  AMOUNT(unit,class)); 

DISPLAY  TOTAMT; 

4ii|>4i4i4<4>4>4i4i3|i4c4ii|ii|'4ci|iifc>l>i|ci|ii|ci|ci|ii|ii|i4ci|i4c4c4c4c4i4ii|t]|ci|i4i4i4i4i4i4ii|c4i4i4>i|ii|ci|c4>4i4>i|ii|i4c4’i|iil'4ii|ii|i 

*  Display  undelivered  cargo  by  unit  and  class...  * 

4ll|ll|l4c**!|l4il|i4c***l|n|el|i4cJ)l!|c*4c!|r!|i!|ci|i4il|c4l4l4rl|l4[4l4i4l*4l4i4i*4tj|ci|t4c!|i*4c4i*l|l4el|ic|(*l|i!|l4cl|lj|el|el|l 


DISPLAY  Z.L; 
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i^^i^,^ll^^,^l*^,0^i^t**************1i*^i^Hl**^tiii|l^i***^t*********>^********** 

*  Compute  total  aniount  of  cargo  and  pax  left  undelivered...  * 

0ttHi^it**************************t**1i**1>*****************>i‘***** 

PARAMEEER  UTOTAL(classX 
UTOTAL(class)  =  SUM(unit,  ZIXunit,class)); 

DISPLAY  UTOTAL; 

*t*fll**ili***i^***J^**fHi***:tiiHiilt^t:Htlt‘******************************* 

*  Compute  amount  of  cargo  and  pax  delivered...  * 

*****4i4i*««*i|i**4i4i4[i|i***4t4i**:»*4t4t*4i«*«*4i4t4i4i*4i***«t4r****4i*4t4i4i****4t* 


PARAMETER  DTOTAL(class); 

DTOTAL(class)  =  TOTAMT(class)  -  UTOTAL(class); 

DISPLAY  DTOTAL; 

^^lt*t^l^l^li^*^l***it^*t********************•************************ 

*  Compute  sortie  scheduie  by  plane  and  day...  * 

***4>*i|i4r*i|i*4<%>l>******«>l>4>****<l>4>it>****4i4>*it>*****4i*4>*>|i4'**4<**4r*****4>* 


PARAMETER  SORTIES^time, plane) ; 

SORTIES(time,plane)  =  SUM(  (uniU‘Oute)$DELTA(unit^oute,plane,time), 
X.L(time,unit,plane,'*blk”/oute)$PREFSR(plane,"blk"^oute)  + 
X.L(time,unit,plane,"out”,route)$PREFER^lane,'’out"4‘oute)  + 
X.L(time,unit,plane,"pax"4t}ute)$PREFER(plane,"pax'’/oute) ) ; 
DISPLAY  SORTIES; 

*  Compute  total  number  of  sorties  by  plane  type...  ♦ 


PARAMETER  TOTALS(plane); 

TOTALS^lane)  =  SUM(time,  SORTIES(tirae,plane)); 

DISPLAY  TOTALS; 

•  Compute  total  number  of  sorties...  * 


PARAMETER  TSORT; 

TSORT  =  SUM(pIane,  TOTALS(pIane)); 

DISPLAY  TSORT; 

*  Compute  percent  sorties  flown  by  each  plane  type...  * 


PARAMETER  MIXTURE(plane); 

MDCrURE(pIane)  =  TOTALSCplanej/TSORT; 
DISPLAY  MDOTJRE; 
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*  Compute  percent  of  each  cargo  class  carried  by  each  * 

*  plane  type,..  * 


PARAMETER  PERCENT(class,plane); 

PERCENT(class,plane)$DTOTAL(class)  = 

SUM((unitj:oute,time)$(AMOUNT(unit,class)$DELTA(unit^oute,plane,time)), 
PREFER(plane,class/oute)  *  X.L(time,unit,plane,class4‘Oute) 

+  NONPREF(plane,class^ute)  *  Y.L(time,unit,plane,class^oute))/  DTOTAL(class); 

DISPLAY  PERCENT, 

^nnm********************************************************* 

*  Compute  percent  of  each  cargo  only  (bulk  +  outsize)  carried  by  each  * 

*  plane  type...  * 

^,:lf^iilf**i(Hiim*i^*^1t^i^i^Hi***t**t*********************************** 

PARAMETER  PCARGO(plane>, 

PCARGO(plane)$(pTOTAL("blk">f  DTOTALC’out"))  = 

SUM((time,unit,route,class)$(DELTA(unit,route,plane,time) 

$(AMOUNT(unit,class)$cargo(class))), 

PREFER(plane,class,route)  *  KL(time,unit,plane,class,route) 

+  NONPREF(plane,class,route)  *  Y.L(time,unit,plane,class,route)) 

/  (DTOTAL("bIk">fDTOTAL("out")); 

DISPLAY  PCARGO; 

*  Compute  pool  of  flying  hours  available  to  each  plane  * 

*  type...  * 

^i^^,t,^*im**iH,4it***************************‘******************** 


PARAMETER  ACTHOURS(period,base,plane); 

ACTHOURS(period,base,plane)  =  SlJM(time$UTEPRD(period,time), 
SUM((unit,classjoute,vtinc)$(n^YTIM^route,vtinc) 

$(delt^unit,route, plane, time-(ORD(vtinc)-l )) 
$(PREFER(plane,class,route)$HEAD(base4’Oute)))), 
FLYTIME(route,vtinc)  * 

X.L(time-(ORD(vtinc>-l),unit,plane,class,route)) ) ; 

DISPLAY  ACTHOURS; 

*  Compute  total  number  of  aircraft  available  in  each  UTE  period...  * 

4r  4i  4i  4r4i*:(t  4r:(r^:tritc4i:|i:|i4i4i4r4i4i4i4r4t4i4i4i4i4i4i4i  41 


PARAMETER  TPLANES(period,base, plane); 

TPLANES(period,base,plane)  =  SUM(time$(UTEPRD(period,time) 

$(NUMPLANE(plane,base,time)$HOME(base,plane))), 

NLrMPLANE(plane,base,time)); 
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t^itt***********************^^********************************* 

*  Compute  actual  utilization  rate  of  each  plane  type.,.  * 

**0ii^**ii***ii**m**m***.**^i***iii**i^****************************** 


PARAMETER  ACnjTE(period,base,pIane); 

ACTUTE(period,base,plane)$HOME(bie, plane)  = 
(ACTHOlJRS(period,base,plane)  ♦  TUNITS)  /  TPLANES(period,base, plane); 
DISPLAY  ACTUTE; 

**4i4>***4t*4i«***4i4r4i****4i**********4i4t***4i*4t4t*4>***4i**4iiti*4i**4i***** 

♦  Con:q>ute  the  actual  fly  rate  of  the  juicraft...  * 


PARAMETER  AVGHOljRS(period,base, plane);  _ 

AVGHOURS(period,baj«, plane)  =  ACTHOURS(period,base,plane)/lJTENlJM(peiiod); 
PARAMETER  FLYRATE(period,b£Be,plane); 

FLYRATE(period,base,plane)$AAVAILO)eriod,base, plane)  = 

AVGHOURS(period, base, plane)  /  AAV  AIL(period,base, plane); 


95 


Appendix  D:  Desert  Shield  Fli^t  and  Grovad  Times 


TABLE  22 


Estimated  Fli^t  Time  Between  Airfields 
(Source:  AMC/XPYR) 


Qngiji 

Destination 

Crl 

C^141 

KCrin 

B.r.747 

B-7Q7 

DC-IP 

P-T47 

KDOV 

KFOE 

3.1 

3.1 

3.1 

3.1 

3.1 

3.1 

3.1 

KFOE 

KCEF 

3.1 

3.1 

3.1 

3.1 

3.1 

3.1 

3.1 

KCEF 

LETO 

7.5 

7.5 

7.5 

7.5 

15 

15 

7.5 

LETO 

OEDR 

6.9 

7.1 

6.9 

6.9 

6.9 

6.9 

6.9 

LETO 

OEDF 

6.9 

7.1 

6.9 

6.9 

6.9 

6.9 

'6.9 

LETO 

OEJB 

6.9 

7.1 

6.9 

6.9 

6.9 

6.9 

6.9 

LETO 

OEKK 

6.9 

7.1 

6.9 

6.9 

6.9 

6.9 

6.9 

OEDR 

LEZA 

8.2 

8.2 

8.2 

8.2 

8.2 

8.2 

8.2 

OEDF 

LEZA 

8.2 

8.2 

8.2 

8.2 

8.2 

8.2 

8.2 

OEJB 

LEZA 

8.2 

8.2 

8.2 

8.2 

8.2 

8.2 

8.2 

OEKK 

LEZA 

8.2 

8.2 

8.2 

8.2 

8.2 

8.2 

8.2 

OEDR 

LETO 

8.2 

8.2 

8.2 

8.2 

8.2 

8.2 

8.2 

OEDF 

LETO 

8.2 

8.2 

8.2 

8.2 

8.2 

8.2 

8.2 

OEJB 

LETO 

8.2 

8.2 

8.2 

8.2 

8.2 

8.2 

8.2 

OEKX 

LETO 

8.2 

8.2 

8.2 

8.2 

8.2 

8.2 

8.2 

LETO 

KDOV 

8.6 

8.9 

8.6 

8.6 

8.6 

8.6 

8.6 

KCEF 

EDAF 

7.6 

7.9 

7.6 

7.6 

7.6 

7.6 

7.6 

EDAF 

OEDR 

7.2 

74 

7.2 

7.2 

7.2 

7.2 

7.2 

EDAF 

OEDF 

7.2 

7.4 

7.2 

7.2 

7.2 

7.2 

7.2 

EDAF 

OEJB 

7.2 

7.4 

7.2 

7.2 

7.2 

7.2 

7.2 

EDAF 

OEKK 

7.2 

7.4 

7.2 

7.2 

7.2 

7.2 

7.2 

EDAR 

OEDR 

6.9 

7.1 

6.9 

6.0 

6.9 

6.9 

6.9 

EDAR 

OEDF 

6.9 

7.1 

6.9 

6.9 

6.9 

6.9 

6.9 

EDAR 

OEJB 

6.9 

7.1 

6.9 

6.9 

6.9 

6.9 

6.9 

EDAR 

OEKK 

6.9 

7.1 

6.9 

6.9 

6.9 

6.9 

6.9 

OEDR 

EDAF 

7.8 

8.4 

7.8 

7.8 

7.8 

7.8 

7.8 

OEDF 

EDAF 

7.8 

8.4 

7.8 

7.8 

7.8 

7.8 

7.8 

OEJB 

EDAF 

7.8 

8.4 

7.8 

7.8 

7.8 

7.8 

7.8 

OEKK 

EDAF 

7.8 

8.4 

7.8 

7.8 

7.8 

7.8 

7.8 

OEDR 

EDAR 

8.0 

8.2 

8.0 

8.0 

8.0 

8.0 

8.0 

OEDF 

EDAR 

8.0 

8.2 

8.0 

8.0 

8.0 

8.0 

8.0 

OEJB 

EDAR 

8.0 

8.2 

8.0 

8.0 

8.0 

8.0 

8.0 

OEKK 

EDAR 

8.0 

8.2 

8.0 

8.0 

8.0 

8.0 

8.0 

EDAF 

KDOV 

9.3 

9.6 

9.3 

9.3 

9.3 

9.3 

9.3 

EXXX 

KDOV 

9.3 

9.6 

9.3 

9.3 

9.3 

9.3 

9.3 

KCHS 

KFOE 

2.5 

2.5 

2.5 

2.5 

2.5 

2.5 

2.5 

KFOE 

KWRI 

2.7 

2.7 

2.7 

2.7 

2.7 

2.7 

2.7 

KWRI 

LETO 

7.4 

7.7 

7.4 

7.4 

7.4 

7.4 

7.4 

LETO 

KCHS 

9.8 

9.8 

9.8 

9.8 

9.8 

9.8 

9.8 

LEZA 

KCHS 

9.8 

9.8 

9.8 

9.8 

9.8 

9.8 

9.8 

LEZA 

OEKK 

8.2 

8.2 

8.2 

8.2 

8.2 

8.2 

8.2 

KWRI 

EDAF 

8.0 

8.0 

8.0 

8.0 

8.0 

8.0 

8.0 
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EDAF 

KCHS 

10.0 

10.6 

10.0 

10.0 

10.0 

10.0 

10.0 

KDOV 

LETO 

7.5 

7.7 

7.5 

7.5 

7.5 

7.5 

7.5 

KDOV 

EDAF 

8.0 

8.1 

8.0 

8.0 

8.0 

8.0 

8.0 

KDOV 

EXXX 

8.0 

8.1 

8.0 

8.0 

8.0 

8.0 

8.0 

KCHS 

KDOV 

1.4 

15 

1.4 

1.4 

1.4 

1.4 

1.4 

KNON 

KFOE 

2.5 

25 

2.5 

2.5 

2.5 

2.5 

2.5 

KNON 

KDOV 

0.0 

0.0 

0.2 

1.2 

1.2 

0.2 

0.2 

EXXX 

EDAF 

0.0 

0.0 

0.2 

1.2 

1.2 

0.2 

0.2 

KFOE 

EXXX 

8.2 

8.2 

8.2 

8.2 

8.2 

8.2 

8.2 

EXXX 

OEDR 

7.3 

7.3 

7.3 

7.3 

7.3 

7.3 

7.3 

EXXX 

OEDF 

7.3 

7.3 

7.3 

7.3 

7.3 

7.3 

7.3 

EXXX 

OEKK 

7.3 

7.3 

7.3 

7.3 

7.3 

7.3 

7.3 

EXXX 

OEIB 

7.3 

7.3 

7.3 

7.3 

7.3 

7.3 

7.3 

OEDR 

EXXX 

8.3 

8.3 

8.3 

8.3 

8.3 

8.3 

8.3 

OEDF 

EXXX 

8.3 

8.3 

8.3 

8.3 

8.3 

8.3 

8.3 

OEJB 

EXXX 

8.3 

8.3 

8.3 

8.3 

8.3 

8.3 

8.3 

OEKK 

EXXX 

8.3 

8.3 

8.3 

8.3 

8.3 

8.3 

8.3 

EXXX 

KNON 

95 

9J 

9.5 

9.5 

9.5 

9.5 

9.5 

EDAF 

EDAF 

0.2 

0.2 

0.2 

0.2 

0.2 

0.2 

0.2 

EDAR 

EDAF 

0.2 

0.2 

0.2 

0.2 

0.2 

0.2 

0.2 

EDAR 

EDAR 

0.2 

0.2 

0.2 

0.2 

0.2 

0.2 

0.2 

TABLE  23 

Average  Ground  Times  AiKXdft  Type 
(Source:  AMCTXPYR) 


Aircraft  Type 

On-lnad 

Enroute 

Qff-load 

C-5 

4.25 

3.25 

3.25 

C-141 

3.25 

2.25 

2.25 

B-747 

4.00 

2.25 

4.00 

B.707 

3.25 

2.25 

2.25 

DC-10 

4.00 

2.25 

4.00 

P-747 

4.00 

2.25 

4.00 
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Appendix  E:  ACEP  Desert  Shield  Model 


*  Hlenar.te:  desert.gins  * 

¥  * 

*  Purpose:  Validation  version  of  Airlift  Capabilities  * 

*  Estimation  Prototype  (ACEP)  model  using  data  from  * 

*  Operation  Desert  Shield.  * 

*  * 

*  Version:  1.5  Date:  30  Jan  1993  * 

**4i4i***]|i¥4i4>¥***4i4i*¥yi¥4i*i|t«****4i**¥4r¥***¥*¥*4'*«4>4t¥¥**4>*4'4i¥¥****¥¥*¥ 

SOFFTEXT 

SOFFSYMXREF 

SOFFSYMUST 

OPTIONS  niERLIM=75000,RESLIM=25000 ; 

OPTIONS  LIMCOL=0,LIMROW=O ; 

OPTION  SOLPRINT=OFF ; 

SET  day  Periods  In  The  Model 

/COl  *C34/; 

alias(day,day3) ; 

SET  unit  Unit  Requiring  Movement  Of  Cargo  Or  Pax 

/U01*U13/; 

SET  plane  Types  Of  Planes 
/  C005,  C141 ,  B747,  B707,  DCIO,  P747  / 

SET  class  Types  Of  Cargo  Or  Pax 
/  blk,  pax,  out  / ; 

SET  cargo(class)  Cargo  types  only 
/Uk,out/; 

SET  base  All  Bases  Considered  In  The  Model 
/KDOV,  KCEF,  KCHS,  KWRI,  KFOE,  EDAF,  LETO,  OEDR, 

KNON,  EXXX,  EDAR,  LEZA,  OEJB,  OEKK,  OEDF  / ; 

SET  route  Routes  By  Which  Cargo  Can  Move 
/R001*R032/; 

SET  vtinc  Time  Increments  In  Paths 
/0*4/; 

SET  deIta(unit,route,plane,day)  Fea'fible  Pickup  Times 
/  U01.R001.C005.(C01*C30) 

U01.(R004,R007).C141.(C01*C30) 

UOl  .R032.P747.(C01  *C30', 

U02.R002.C005.(C01  *C30) 
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U02.(R005.R008).C  1 41  .(COl  *C30) 
U03.R003.C005.(C01  *C30) 

U03.R027.P747.(C01  *C30) 

U04.(R006.R009).C141.(C01  *C30) 

U05.(R010,R028).(C005,B747).(C01*C30) 

U05.(R013.R016).C141.(C01*C30) 

U06.(R011,R029).(C005,B707,B747).(C01*C30) 

U06.(R014,R017).C141.(C01*C30) 

U07.(R012,R019,R030).(C005,B707,B747).(C01*C30) 

U07.(R015,R018).C141.(C01*C30) 

U08.R020.C005,(C01  *C30) 

U08.R026.C141  .(COl  *C30) 

U08.R031  .DC10.(C01  *C30) 

U09;R021.C005.(C01  *030) 

U10.R022.C005.(C01  *C30) 
U11.R023.C141.(C01*C30) 

U12.R024.C141  .(COl  *C30) 

U13.R025.C141.(C01  *C30)  / ; 

TABLE  AMOUNT(unit,class)  Amount  To  Be  Moved 


blk 

pax 

out 

UOl 

6500 

6850 

5670 

U02 

2800 

3536 

3276 

U03 

25930 

2646 

U04 

3375 

U05 

36378 

25160 

U06 

4582 

2176 

U07 

9704 

5168 

U08 

2079 

7178 

1764 

U09 

252 

1224 

882 

UlO 

567 

1564 

882 

Ull 

3393 

U12 

1034 

U13 

1307 

PARAMETER  TCLASS(class); 

TCLASS(class)  =  SUM(unit,  AMOUNT(unit, class)); 
DISPLAY  TCLASS; 

SCALAR  RATIO/0.86/; 


PARAMETER  FLYTIME(route,vtinc)  Flight  Time  Between  Stops 
/  ROOl.O  13.7,  ROOM  17.2,  R001.2  6.6 
R002.0  13.7,  R002.1  17.2,  R002.2  6.6 
R003.0  13.7,  R003.1  17.2,  R003.2  6.6 
R004.0  15.7,  R004.1  20.2,  R004.2  1.6 
R005.0  15.7,  R005.1  20.2,  R005.2  1.6 
R006.0  1 5.7,  R006. 1  20.2,  R006.2  1.6 
R007.0  15.7,  R007.1  20.2,  R007.2  1.6 
R008.0  15.7,  R008.1  20.2,  R008.2  1.6 
R009.0  15.7,  R009.1  20,2,  R009.2  1.6 
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R010.0  21.6,R010.1  9.6 
ROl  1.0  21.6,  ROl  1.1  9.6 
R012.021.6,R012.1  9.6 
R013.0  16.3,  R013.1  18.0 
R014.016.3,R014.1  18.0 
R015.0  16.3,  ROl 5.1  18.0 
R016.0  16.3,  R016.1  18.0 
R017.0  16.3,  R017.1  18.0 
R018.0  16.3,  R018.1  18.0 
R019.0  15.3,R019.1  17.8 
R020.0  15.3 
R021. 015.3 
R022.0  15.3 
R023.0  15.3 
R024.0  15.3 
R025.0  15.3 
R026.0  15.3 

R027.0  16.7,  R027.1  17.6,  R027.2  1.5 
R028.0  16.3,  R028.1  17.3,  R028.2  0.5 
R029.0  16.3,  R029.1  17.3,  R029.2  0.5 
R030.0  16.3,  R030.1  17.3,  R030.2  0.5 
R031.015.7 

R032.0  17.7,  R032.1  17.8,  R032.2  0.3  /; 


SET  legtime(route,base,vtinc)  Time  Increment  at  Intermediate  Stops 
/ R001.(KDOV.C  KFOE.0,KCEF.0,LETO.l,OEPR.l,LETO.2,KDOV.2) 
R002.(KDOV.0,KFOE.0,KCEF.0,LETO.l,OEJB.l,LETO.2,KDOV.2) 
R003.(KDOV.0,KFOE.0,KCEF.0,LETO.l,OEDF.l,LETO.2,KDOV.2) 
R004.(KCHS.O,KFOE.O,KWRI.O,LETO.O,OEDR.  1  ,LEZA.2,KCHS.2) 
R005.(KCHS.O,KFOE.O,ICWRI.O,LETO.O,OEJB.1,LEZA.2,KCHS.2) 
R006.(KCHS.O,KFOE.O,KWRI.O,LETO.O,OEKK.1,LEZA.2,KCHS.2) 
R007.(KCHS.O,KFOE.O,KWRI.O,LETO.O,OEDR.  1  ,LET0.2,KCHS.2) 
R008.(KCHS.O,KFOE.O,KWRI.O,LETO.O,OEJB.  1  ,LET0.2,KCHS.2) 
R009.(KCHS.O,KFOE.O,KWRI.O,LETO.O,OEKK.1,LET0.2,KCHS.2) 
R010.(KDOV.O,LETO.O,OEDR.O,LET0.1,KDOV.l) 
R011.(KDOV.O,LETO.O,OEJB.O,LET0.1,KDOV.l) 
R012,(KDOV.O,LETO.O,OEKK.O,LET0.1,KDOV.1) 
R013.(KCHS.O,KDOV.O,LETO.O,OEDR.l,LEZA.l,KCHS.l) 
R014.(KCHS.O,KDOV.O,LETO.O,OEJB.l,LEZA.l,KCHS.l) 
R015.(KCHS.O,KDOV.O,LETO.O,OEKK.l,LEZA.l,KCHS.l) 
R016.(KCHS.O,KDOV.O,LETO.O,OEDR.l,LET0.1,KCHS.l) 
R017.(KCHS.O,KDOV.O,LETO.O,OEJB.l,LET0.1,KCHS.l) 
R018.(KCHS.O,KDOV.O,LETO.O,OEKK.I,LET0.1,KCHS.l) 

ROl  9.(KNON.O,KDO  V.O,EXXX.O,r.  EKK.  1  ,EXXX.  1  ,KNON.  1 ) 
R020.(EDAF.0,OEDR.0,EDAF.  1 ) 

R021.(EDAF.0,OEJB.0,EDAF.l) 

R022.(EDAF.0,OEKK.0,EDAF.  1 ) 

R023.(EDAR.0,OEDR.0,EDAR.  1 ) 

R024.(EDAR.0,OEJB.0,EDAR.  1 ) 

R025.(EDAR.0,OEXK.0,EDAR.l) 

R026.(EDAR.0,EDAF.0,OEDR.0,EDAR.l) 
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R027.(KNON.O,KFOE.O,EXXX.O,OEDF.1,EXXX.1,KNON.2) 

R028.(KNON.O.KDOV.O,EXXX.O,OEDR.1,EXXX.1,KNON.2) 

R029.(KNON.O,KDOV.O,EXXX.O,OEJB.1,EXXX.1,KNON.2) 

R030.(KNON.O,KDOV.O,EXXX.O,OEKK.1,EXXX.1,KNON.2) 

R031.(EXXX.O,EDAF.O,OEDR.O,EXXX.1) 

R032.(KNON.O,KFOE.O,EXXX.O,OEDR.1,EXXX.1,KNON.2)  / ; 

SET  onload(unit,base)  Onload  Point  For  Each  Unit 
/  (U01,U02,U03.U04).KFOE 
(U05,U06,U07).KDOV 
(U08,U09,U10).EDAF 
(U11,U12.U13).EDAR  /; 


SET  offload(unit,base)  Offload  Point  For  Each  Unit 
/  (UOl  ,U05,U0P,U1  l).OEDR 
(U02,U06,U09,U12).OEJB 
(U03),OEDF 

(U04.U07.U10,U13).OEKK  / ; 

PARAMETER  numplane(plane,day)  Number  Of  Aircraft  Available 
/C005.(C01*C34)  112 
C141.(C01*C34)  230 
B747.(C01*C34)  10 

B707.(C01*C34)  15 

DC10.(C01*C34)  5 

P747.(C01*C34)  10  /; 

SET  period  UTE  Periods  Tracked  by  Model 
/Sustain/; 


SET  UTEdays(period,day)  Days  Covered  by  UTE  Periods 
/Sustain.(C01*C30)/; 

PARAMETER  UTEnum(period)  Number  of  days  in  each  period 
/Sustain  30/; 


TABLE  UTEtate(period,plane)  Objective  UTE  Rates  for  Aircraft 
C141  COOS  B747  B707  DCIO  P747 
Sustain  10.0  9.0  10.0  10.0  10.0  10.0  ; 

PARAMETER  UTEhours(period,pIane) ; 
UTEhours(period,plane)  =  SUM(day$(UTEdays(period,day) 
$NUMPLANE(plane,day)),  NUMPLANE(plane,day)  * 
UTErate(period,plane) ) ; 


TABLE  CYCLE(route, plane)  Length  Of  Roundtrip  in  Days 
C141  COOS  B747  B707  DCIO  P747 
4 


ROOl 

R002 

R003 

R004 


4 

4 

4 

4 


4 

4 

4 

4 


4 

4 

4 


4 

4 

4 

4 


4 

4 

4 

4 


4 

4 

4 

4 
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ROO^ 

R006 

R007 

R008 

R009 

ROlO 

ROll 

R012 

R013 

ROM 

R015 

R016 

R017 

R018 

R019 

R020 

R021 

R022 

R023 

R024 

R025 

R026 

R027 

R028 

R029 

R030' 

R031 

R032 


PARAMETER  PARK(base,day)  Parking  MOG  Limits  At  Each  Base 
/KDOV.(C01*C34)  500 
KCEF.(C01*C34)  500 
KCHS.(C01*C34)  500 
KWRI.(C01*C34)  500 
KFOE.(C01*C34)  500 
KNON.(C01*C34)  500 
EDAF.(C01*C34)  144 
EXXX,(C01*C34)  500 
EDAR.(C01*C34)  42 
LETO.(C01*C34)  160 
LEZA.(C01*C34)  24 

OEDR.(C01*C34)  40 
OEJB.(C01*C34)  15 

OEKK.(C01*C34)  31 
OEDF.(C01*C34)  40  /; 


PARAMETER  THRU(base,day,class)  Throughput  Limits 
/KFOE.(C01*C34).pax  15000 
KFOE.(C01*C34).blk  5000 
KDOV.(C01*C34).pax  15000 
KDOV.(C01*C34).blk  5000 
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EDAF.(C01*C34).pax  15000 
EDAF.(C01*C34).blk  5000 
EDAR.(C01*C34).pax  15000 
EDAR.(C01*C34).blk  5000 
OEDR.(C01*C34).pax  11000 
OEDR.(C01*C34).blk  2500 
OEJB.(C01*C34).pax  7300 
OEJB.(C01*C34).blk  1500 
OEDF.(C01*C34).pax  4100 
OEDF.(C01*C34).blk  1400 
OEKK.(C01*C34).pax  1600 
OEKK.(C01*C34).blk  450  /; 

TABLE  MOG(base, plane)  Mog  Used  By  Each  Plane  Type  At  E^h  Base 


C141 

C005 

B747 

B707 

DCIO 

P747 

KDOV 

1 

2 

2.1 

1 

2 

2.1 

KCEF 

1 

2 

•2.1 

1 

2 

2.1 

KCHS 

1 

2 

2.1 

1 

2 

2.1 

KWRI 

1 

2 

2.1 

1 

2 

2.1 

KFOE 

1 

2 

2.1 

1 

2 

2.1 

EDAF 

1 

2 

2.1 

1 

2 

2.1 

1^0 

1 

2 

2.1 

1 

2 

2.1 

OEDR 

1 

2 

2.1 

1 

2 

2.1 

KNON 

1 

2 

2.1 

1 

2 

2.1 

EXXX 

1 

2 

2.1 

1 

2 

2.1 

EDAR 

1 

2 

2.1 

1 

2 

2.1 

LEZA 

1 

2 

2.1 

1 

2 

2.1 

OEIB 

1 

2 

2.1 

1 

2 

2.1 

OEKK 

1 

2 

2.1 

1 

2 

2.1 

OEDF 

1 

2 

2.1 

1 

2 

2.1 

TABLE  RHO(unit,class)  Penalty  For  Shortfall 


blk 

pax 

out 

UOl 

10 

10 

10 

U02 

10 

10 

10 

U03 

10 

10 

10 

U04 

10 

10 

10 

U05 

10 

10 

10 

U06 

10 

10 

10 

U07 

10 

10 

10 

U08 

10 

10 

10 

U09 

10 

10 

10 

UlO 

10 

10 

10 

Ull 

10 

10 

10 

U12 

10 

10 

10 

U13 

10 

10 

10  ; 

TABLE  NU(unit, plane)  Penalty  For  Each  Sortie  Flown 


UOl 

U02 


C141  C005  B747  B707  DCIO  P747 
111111 
111111 
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U03  1  1  1  1  I  1 

U04  111111 

U05  1  1  1  1  1  1 

U06  111111 

U07  1  11  11  1 

U08  111111 

U09  111111 

UlO  111111 

Ull  111111 

U12  111111 

U13  1  1  1  11  1  ; 

PARAMETER  PREFER(pIane,class^ute)  Hane  Capacities  Fa  Preferred  Cargo 
/C141.blk.(R001*R030)  27.5 

C141.pax,(R001*R030)  136.0 

C(X)5.out.(R001*R030)  68.9 

C005.blk.(R001*R030)  68.9 

B747.blk.(R001*R030)  87.3 

B707.blk.(R001*R030)  41.1 

DC10.pax.(R001*R030)  235.0 
P747.pax.(R001*R030)  365.0  /; 


PARAMETER  NONPREF(plane,class/oute)  edacities  For  Nonpreferred  Cargo 
/C005.pax.(R001*R030)  75.0 

C141.pax.(R001*R030)  10.0  /; 


FREE  VARIABLES 

COBJ 

DOBJ 

roSmVE  VARIABLES 
X(day,unit, plane, class, route) 
Y(day,unit,plane,class,route) 
2Xunit,class) 


Cost  of  the  operation 
Total  tonnage  &  pax  delivered 


Number  Of  Sorties 

Opportune  Movement  Of  Nonprefened  Cargo 
Amount  Of  Cargo  Left  Undelivered 


EQUATIONS 

COST 

DELIVER 

DELrVPAX(unit) 

DELrVBLK(unit) 

DELIVOUT(unit) 

NONPREFl  (route,plane,day) 

NONPREF2(route,plane,day) 

AVAIL^lane,day) 

THRUPUTl  (base, day) 

THRUPUT2(base,day) 

MOGLIM(base,day) 

UTELIM(^riod,plane) 

DELRATO 


The  Cost  Otgective  Function 
The  Flow  Objective  Function 
Account  For  All  Pax  Requirements 
Account  For  All  Bulk  Requirements 
Account  For  All  Outsize  Requirements 
Opportune  Cargo  On  Pax  Planes 
C^portune  Pax  On  Cargo  Planes 
Number  Of  Hanes  Available 
Car^  Thruput  At  Onloads  And  Offloads 
Pax  Thruput  At  Onloads  And  Offloads 
Enroute  Constraints 
Otgective  UTE  constraint  on  aircraft 
Ratio  of  delivered  cargo  to  pax 


1(M 


COST..  COBJ  =E=  SUM((unit,class)$AMOUNT(umt,cIass), 

RHO(unit,class)  *  Z(urat, class))  +  SUM((unit,class^oute,plane,day) 
$(delta(umt4'oute,plane,day)$PREFER(plane,class^oute)), 

NU(urat, plane)  *  X(day,unit,plane,class4Bute) ) ; 

DELIVER..  DOBJ  =E=  SUM((day,unit,plane,class;rcmte) 

$delta(uniuoute,plane,day), 

PREFER(plane,class/oute)  *  X(day,umt,plane,class^ute)  + 
NONPREF(plane,class,route)  ♦  Y(day,unit,plane, classmate) ) ; 

DELlVPAX(unit)$AMOUNT(uniCpax")..  AMOUNT(unit,"pax")  =E=  Z(unit,”pax")  + 
SUM((route,plane,day)$delta(uniuoute,plane,day), 

PREFER(j)lane,"pax"^oute)  ♦  X(day,unit,plane,"pax''^oute)  + 
xN[ONPr5F(plane,"pax"^oute)  *  Y(day,umt,plane,''pax"4‘oute) ) ; 

DELIVBLK(unit)$  AMOUNT(unit,"blk")..  AMOUNT(unit,"blk")  =E=  Z(unit,"blk")  + 
SUM((route,plane,day)$delta(unit^oute,plane,day), 

PREFER(plane,"blk"^oute)  *  X(day,unit,plane,"blk"^oute)  + 
NONPREF(plane."blkVoute)  *  Y(day,unit,plane,"blkVoute) ) ; 

DELIVOUT(unit)$AMOl]NT(uniCout")..  AMOUNT(uniCout")  =E=  Z(unit,"out")  + 
SUM((route,plane,day)$delta(umUoute,plane,day), 

PREFER(plane,"out",route)  *  X((iay,unit,plane,"out",route) ) ; 

NONPREFl(route, plane, day)$NONPREF(plane,"blkVoute).. 
SUM(unit$delta(unit,route, plane, day), 
X(day,unit,pIane,"pax”,route)$PREFER(plane,"pax",route)- 
Y(day,unit,plane,"bIk",route)$NONPREF(plane,"blk",route) )  =G=  0.0 ; 

NONPREF2(route,plane,day)$NONPREF(plane,"pitt",route).. 
SUM(unit$delta(unit,route,plane,dayX 
X(day,unit,plane,"out",rbute)$PREFER(plane,"out",route)  + 
X(day,unit,plane,"blk",route)$PREFER^lane,"blk"jroute)- 
Y(day,unit,plane,"pax",route)$NONPREF(plane,"pax",route) )  =G=  0.0; 


AVAIL(plane,day)..  NUMPLANE(plane,day)  =G= 
SL’M((route,day2)$((ORD(day2)  le  ORD(day))  and 
(ORD(da^)  gt  (ORD(day)  -  CYCLE(route,plane))) ), 

SUM((unit,class)  $(delta(unit/oute,plane,day2) 
$PREraR^lane,class,route)),  X(day2,unit,plane,class,route) ) ) ; 

THRUPUTl(base,day)$THRU(base,day,"blk")..  THRU(base,day,"blk'’)  =G= 
SUM(unit$onload(unit,base), 
SUM((route,plane)$delta(unit,route,plane,day), 

PREraR(plane,"blk",route)  *  X(day,iinit,plane,"blk",route)  + 
PREFER(plane,"out",route)  *  X(day,unit,plane,"out",route)  + 
NONPREF(plane,"blk"4'oute)  *  Y(day,unit,plane,"blk",route) ) )  + 

SUM(unit$offload(unit,base), 

SUM((route,plane,vtinc)$(legtime(route,base,vtinc) 
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$delta(unit^oute, plane, day-(ORD(vtinc)-l))), 

PREFER(plane,"b!k",route)  *  X(day-(ORD(vtinc)-l),unit,plane,"blk"4-oute)  + 
PREFER(plane,"out",route)  *  X(day-(ORD(vtinc)-l),unit,plane,"out"joute)  + 
NONPREF(plane,"blk"4-oute)  *  Y(day-(ORD(vtinc)-l),unit,plane,"blk",route))); 

THRUPUT2(base,day)$THRU(base,day,"pax").-  THRU(base,day,"pax")  =G= 
SUM(umt$onload(iinit,base), 

SUM((route,plane)$delta(unit4'oute,plane,day), 

RlEraR(plane,"pEx",route)  *  X(day,unit,plane,"pax",route)  + 
NONPREF(plane,"pax",route)  •  Y(day,unit,plane,’'pax",route) ) )  + 

SUM(unit$offload(unit,base), 

SUM((route, plane, vtinc)  $(legtime(route,base,vtinc) 

$delt^unit,route:plane,day- (ORD(vtinc)-l ))), 

PREFER(plane,"pax",route)  *  X(^y-(ORD(vtinc)-l),unit,plane,"pax",route)  + 
NONPREF(plane,"pax",route)*  Y(day'(ORD(vtinc)-l),unit,plane,"pax",route))); 

MOGLIM(base,day)$PARK(base,day)..  PARK(base,day)  =G= 
SUM((unit,class4‘oute,plane,vtinc)$Gegtime(route,base,vtinc) 
$(delt^uni£,route,plane,day-(ORD(vtinc)-l))  $PREFER(plane,class4‘oute))), 
MCX5(base,plane)  *  X(^y-(ORD(vtinc)-l),unit,plane,class,route) ) ; 

trTELIM(period,plane)..  lJTEhours(period,plane)  =G= 
SUM(day$UTEdays^eriod,day),  SUM((unit,class,route,  vtinc) 
$(FLYTlME(route,vtinc)$(^lt^unit,route,pIane,day-(ORD(vtinc)- 1 )) 
$PREFER(plane,class  joute))),  FLYTIME(route,vtinc)  * 
X(day-(ORD(vlinc)-l),unit,plane,cIass,route)) ) ; 

DELRATO..  SUM((day,umt,plane,class/oute) 
$(delta(unit,route,plane,day)$(aniount(unit,c!ass)$cargo(cIass))), 
PREFER(plane,class,route)  *  X(day,unit,plane,class,route) ) 

-  RATIO  *  SUM((day,unit,plane/oute)$delt^unit,route,plane,day), 
PREFER(plane,"pax",route)  ♦  X(day,unit,plane,"pax”4'oute) 

+  NONP^F(pIane,"pax"4'oute)  *  Y(day,unit,plane,"pax",route) )  =G=  0.0 ; 

MODEL  ACEPCN/COST,  DELIVPAX,  DELIVBLK,  DELIVOUT, 

NONPREFl,  NONPREF2,  AVAIL,  THRUPUTl, 

THRUPUT2,  MOGLIM,  UTELIM,  DELRATO  / ; 

*  Solve  model  ACEPCN  to  minimize  cost...  * 

*4i*****«4'*******>)>***4r<c*«*«!|>*«4r**4'4'4'*****4'4'»>*>l>**4<**:)'***4'*«>t>*« 

SOLVE  ACEPCN  USING  LP  MINIMIZING  COBJ ; 

PARAMETER  PAVAIUplane)  Max  Percent  of  Available  ACFT  Used; 
PAVAIL(plane)  =  0; 

PARAMETER  AAVAIL(period,plane)  Average  number  used; 
AAVAILQ)eiiod,plane)  =  SUM(day$UTEDAYS^eriod,day), 
-AVAIL.L(plane,day))  /  UTEnum(period) ; 

PARAMETER  MAVAIL(plane)  Marginal  viue  of  Aircraft; 
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MAVAIL(plane)  =  0; 

LOOPCday, 

PAVAIL^lane)$NlJMPLANE(plane,day)  = 

MAX(  PAVAIL(plane).  (-AVAIL.L^Iane,day)  / 
NUMPLAN^lane,day)) ) ; 
MAVAIL(plane)$NUMPLANE(plane,day)  = 

MAVAIL(plane)  +  AVAIL.M(plane,^y) ); 

DISPLAY  PAVAIL; 

DISPLAY  AAVAm 
DISPLAY  MAY  AIL; 

PARAMETER  PCTHRU(base)  Max  percent  of  cargo  thruput  used; 
PCTHRU(base)  =  0; 

PARAMETER  MCTHRU(base)  Marginal  Value  of  Base  (Cargo); 

MCTHRU(base)  =  0; 

LOOP(day. 

PCTHRU(base)$THRU(base,day."blk")  = 

MAX(  PCTHRU(base),  (-THRUPim.L(base,day)  / 
THRU(base,day,"blk")) ); 
MCTHRU(base)$THRU(base,day,"blk")  = 

MCTHRU(base)  +  THRUPUTl  M(base,day) ); 

DISPLAY  PCTHRU; 

DISPLAY  MCTHRU; 

PARAMETER  PPTHRU(base)  Max  percent  of  PAX  thruput  used; 
PPTHRU(base)  =  0; 

PARAMETER  MPTHRUCbase)  Marginal  Value  of  Base  (PAX); 

MPTHRU(base)  =  0; 

LOOP(day, 

PPTHRU(base)$THRU(base,day,’'pax")  = 

MAX(  PPTHRU(base),  (-THRUPUT2.L(base,day)/ 
THRU(base,day,"pax")) ); 
MPTHRU(base)$THRU(base,day,"pax")  = 

MPTHRU(base)  +  THRUPUT2.M(base,day) ); 

DISPLAY  PPTHRU; 

DISPLAY  MPTHRU; 

PARAMETER  PMOG(base)  Max  percent  of  MOG  used; 

PMOG(base)  =  0; 

PARAMETER  MMOG(base)  Marginal  Value  of  Base  (MOG); 

MMOG(base)=0; 

LOOP(day, 

PMOG(base)$PARK(base,day)  = 

MAX(  PMOG(base),  (-MOGLIM.L(base,day)/  PARK(base,day)) ); 
MMOG(base)$PARK(base,day)  = 

MMOG(base)  +  MOGLIM.M(base,day) ); 

DISPLAY  PMOG; 

DISPLAY  MMOG; 

PARAMETER  TnTAMT(class); 

TOTAMT(class)  =  SUM(unit,  AMOUNT(unit,class)); 
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DISPLAY  TOTAMT; 

DISPLAY  ZL; 

PARAMETER  UTOTAL(class); 

UTOTAL(class)  =  SUM(unit,  Z.L(unit,class)); 

DISPLAY  UTOTAL; 

PARAMETER  DTOTAL(dass); 

DTOTAL(class)  =  TOTAMT(class)  -  UTOTAIXcIass); 

DISPLAY  DTOTAL; 

PARAMETER  SORTIES(day, plane) ; 

SORTTESCday, plane)  =  SUM(  (uniMX)ute)$DELTA(unit4t>ute, plane, day), 
X.L(day,unit, plane, "blk'',route)$PREFER(plane,"blk",route)  + 
X.L(day,unit,plane,"out"4'Oute)$PREFER(plane,"out",route)  + 
X.L(day,unit,plane,"pax",route)$PREFER(plane,”pax"4-oute) ) ; 

DISPLAY  SORTIES; 

PARAMETER  TOTALS(plane) ; 

TOTALS(plane)  =  SUM(day,  SORTIES(day,plane)); 

DISPLAY  TOTALS; 

PARAMETER  TSORT; 

TSORT  =  SUM(pIane,  TOTALS(plane)); 

DISPLAY  TSORT; 

PARAMETER  MDCTURE(plane); 

MDCTURECplane)  =  TOTALS(planeyTSORT; 

DISPLAY  MDCTURE; 

PARAMETER  PERCENT(class,plane); 

PERCENT(class,plane)  =  0.0; 

PERCENT(class,plane)$DTOTAL(class)  = 
SUM((unit4:oute,day)$(AMOUNT(unit,class)$DELTA(unit4-oute,plane,day)), 
PREFER^lane,class,route)  *  X.L(day,unit,plane,class,route) 

+  NONP]^F(plane,class,route)  *  Y.L(day,unit,plane,class,route)) 
/DTOTAL(class)i 
DISPLAY  PERCENT; 

i 

PARAMETER  PCARGO(plane); 
PCARGO(pIane)?<DTOTAL("blk>DTOTALC'out"))  = 
SUM((day,unit,routeiclass)$(DELTA(unit4'oute,plane,day) 
$(amount(unit,class)$cargo(class))), 

PREFER^lane,class,We)  •  X.L(day,unit,plane,class,route)) 

/  (DTOTAL("blk”)+DTOTAL("out")); 

DISPLAY  PCARGa,  | 

I 

PARAMETER  ACTHOURS(period,plane); 

ACTHOURS(period,plane)  =  SUM(day$UTEdays(period,day), 
SUM((unit,class4-oute,vtinc)$(FLYTlME(route,vtinc) 
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$(delta(unit/oute,pIane,day-(ORD(vtinc>  1 )) 

'^PREI%R(plane,class^outep,  FLYTIME(route,vtmc)  * 
X.L(day-(ORD(vtinc)-l),unit,plane,cIass,route)) ) ; 

PARAMETER  TPLANES(period,plane); 

TPLANESQ)eriod,plane)  =  SUM(day$(UTEDAYS(period,day) 
$NUMPLANE(plane,day)),  NUMPLANE(plane,day)) ; 

PARAMETER  ACTUTE(period,plane); 

ACTUTE(period,pIane)  ==  0.0; 
ACTUTE^eriod,piane)$TPLANES(period,plane)  = 
ACTHOURS(period,plane)  /  TPLANES(period,plane) ; 

DISPLAY  ACTUTE; 

PARAMETER  AVGHOURS(period,pIane); 

AVGHOURS(period,plane)  =  ACTHOllRS(period,plane)/lJTEnum^eriod); 
DISPLAY  AVGHOURS; 

PARAMETER  FI.YRATE(period,plane); 
FLYRATE(period,plane)$A.\VAIL(period,plane)  = 
AVGHOURS(period,plane)  /  AAVAIL^)eriod,plane); 

DISPLAY  FLYRATE; 
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Appendix  F:  ACEP  Deseit  Shield  Solution 


GENERAL  ALGEBRAIC  MODELING  SYSTEM 
MODEL  STATISTICS  SOLVE  ACEPCN  USING  LP  FROM  LINE  451 

MODEL  STATISTICS 

BLOCKS  OF  EQUATIONS  12  SINGLE  EQUATIONS  2020 
BLOCKS  OF  VARIABLES  4  SINGLE  VARIABLES  3028 
NON  ZERO  ELEMENTS  36745 

GENERATION  TIME  =  162.920  SECONDS 

EXECUTION  TIME  =  163.810  SECONDS 

SOLUTION  REPORT  SOLVE  ACEPCN  USING  LP  FROM  LINE  451 


SOLVE  SUMMARY 


OBJFCTIVE  COBJ 
DIRECTION  MINIMIZE 
FROM  LINE  451 


MODEL  ACEPCN 
TYPE  LP 
SOLVER  MINOS5 

****  SOLVER  STATUS 
*♦**  MODEL  STATUS 
****  OBJECTIVE  VALUE 


1  NORMAL  COMPLETION 
1  OPTIMAL 
143340.8916 


RESOURCE  USAGE,  LIMIT  5053.780  25000.000 
ITERATION  COUNT,  LIMIT  29695  75000 


MINOS  5.2  (Mht  1988) 


B.  A.  Murtagh,  University  of  New  South  Wales 
and 

P.  E.  Gill,  W.  Murray,  M.  A.  Saunders  and  M.  H.  Wright 
Systems  Optimization  Laboratory,  Stanford  University. 

Work  space  needed  (estimate)  -  204090  words. 

W'ork  space  available  -  244909  words. 

EXIT  -  OPIIMAL  SOLUTION  FOUND 


REPORT  SUMMARY;  0  NONOPT 

0  INFEASIBLE 
0  UNBOUNDED 
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—  466  PARAMETER  PAVAIL  MAX  PERCENT  OF  AVAILABLE  ACFT  USED 

COOS  1.000,  C141  0.183,  B747  1.000,  P747  1.000 

—  467  PARAMETER  AAVAIL  AVERAGE  NUMBER  USED 

COOS  C141  B747  P747 

SUSTAIN  98.1S8  17.769  9.488  7.420 

—  468  PARAMETER  MA VAIL  MARGINAL  VALUE  OF  AIRCRAFT 

COOS  EPS,  B747  1496.000,  P747  EPS 

—  480  PARAMETER  PCTHRU  MAX  PERCENT  OF  CARGO  THRUPUT  USED 

KDOV  0.747,  KFOE  0.379,  EDAF0.28S,  OEDR  0.610,  EDAR  0.148 
OEJB  0.344,  OEKK  1.000,  OEDF  0.901 

—  481  PARAMETER  MCTHRU  MARGINAL  VALUE  OF  BASE  (CARGO) 
OEKKS03.087 

—  493  PARAMETER  PPTHRU  MAX  PERCENT  OF  PAX  THRUPUT  USED 

KDOV  0.266,  KFOE  0.281,  EDAF  0.103,  OEDR  0.232,  OEJB  0.077, 

OEKK  0.306,  OEDF  0.890 

—  494  PARAMETER  MPTHRU  MARGINAL  VALUE  OF  BASE  (PAX) 

(ALL  ZERO) 

—  SOS  PARAMETER  PMOG  MAX  PERCENT  OF  MOG  USED 

KDOV0.3S6,  KCEF  0.172,  KCHS  0.274,  KWRI  0.073,  KFOE  0.181 
EDAF0.4S9,  LETO  1.000,  OEDR  1.000,  KNON  0.072,  EXXX  0.090 
EDAR  1.000,  LEZA  1.000,  OEJB  1.000,  OEKK  1.000,  OEDF  1.000 

—  S06  PARAMETER  MMOG  MARGINAL  VALUE  OF  BASE  (MOG) 

LETO  0.119,  OEDR  1S970.929,  EDAR  EPS,  LEZA  EPS 
OEJB  3499.166,  OEKK  EPS,  OEDF  EPS 

—  SIO  PARAMETER  TOTAMT  TOTAL  AMOUNT  TO  BE  MOVED 

BLK  71971.000,  PAX  78786.000,  OUT  1S120.000 


512  VARIABLE  Z.L 


AMOUNT  OF  CARGO  LEFT  UNDELIVERED 


BLK 

UOl  4928.447 
U04  1885.000 
U05  4007.653 
Ull  3393.000 

—  516  PARAMETER  UTOTAL  TOTAL  SHORTFALL 

BLK  14214.100 

—  520  PAR/,METER  DTOTAL  TOTAL  AMOUNT  DELIVERED 

BLK  57756.900.  PAX  78786.000.  OUT  15120.000 


—  527  parameter  SORTIES 


C005 

C141 

B747 

COl 

29.762 

4.066 

C02 

60.511 

5.934 

C03 

21.726 

C04 

29.762 

4.066 

C05 

20.318 

5.934 

C06 

41.514 

16.364 

C07 

29.762 

4.066 

COS 

25.962 

16.364 

5.934 

C09 

9.216 

CIO 

49.200 

4.066 

Cll 

27.800 

5.934 

C12 

27.500 

C13 

23.240 

8.593 

C14 

53.760 

C15 

28.252 

10.000 

C16 

26.887 

31.238 

C17 

5.418 

10.762 

C18 

36.576 

10.000 

C19 

31.400 

C20 

36.662 

C21 

29.906 

10.000 

C22 

12.656 

C23 

32.347 

C24 

27.076 

16.364 

10.000 

C25 

30.168 

25.636 

C26 

16.031 

C27 

14.031 

15.000 

10.000 

C28 

34.031 

C29 

22.675 

12.326 

C30 

41.263 

8.683 

10.000 

SCHEDULE  OF  AIRLIFT  MISSIONS 

P747 

3.150 

6.850 

3.150 

10.000 

10.000 

10.000 

10.000 

10.000 
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~  531  PARAMETER  TOTALS  TOTAL  MISSIONS  BY  AIRCRAFT  TYPE 

COOS  875.412,  C141  161.329,  B747  100.000,  P747  63.150 
535  PARAMETER  TSORT  =  1199.892 

—  539  PARAMETER  MIXTURE  SHARE  OF  MISSIONS  BY  AIRCRAFT  TYPE 

COOS  0.730,  C141  0.134,  B747  0.083,  P747  0.053 

—  548  PARAMETER  PERCENT  SHARE  OF  CARGO  BY  AIRCRAFT  TYPE 


COOS 

C141 

B747 

P747 

BLK  0.783 

0.066 

0.151 

PAX  0.669 
OUT  1.000 

0.038 

0.293 

—  556  PARAMETER  PCARGO 

COOS  0.828,  C141  0.053, 

B747  0.120 

—  573  PARAMETER  ACTUTE 

ACTUAL  UTE  RATE  ACHIEVED 

COOS 

C141 

B747 

P747 

SUSTAIN  8.144 

0.528 

10.000 

7.486 

~  582  PARAMETER  FLYRATE 

FLY  RATE  ACHIEVED 

COOS 

C141 

B747 

P747 

SUSTAIN  9.327 

7.344 

10.345 

9.655 

••••FILE  SUMMARY 

INPUT  GOR93M:IRMCCANNE.ACEP]DESERT.GMS;44 
OUTPUT  GOR93M:tRMCCANNEACEP]DESERT.LIS;34 

EXECUTION  TIME  =  1 6.900  SECONDS 
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